• Please review our updated Terms and Rules here

Commodore 8032 add-on board - SuperPET

I have a 'first cut' of the schematics done - but the file is a bit large to upload to the forum. If anyone wants a copy of the schematics in PDF form - PM me and I will send you a copy for comment.

There are a few things outstanding at the moment:

1. The title blocks on the individual schematics need tidying up.
2. There is a DRC error for the PHI2 clock pin of the 65C02 CPU (not sure what to do with it at the moment - I suspect it should be my SYSTEM_E clock).
3. There are some DRC errors on unused pins of the EEPLD (Atmel ATF1508AS for the glue logic).
4. I may need to put the 65C02 into "not ready" mode (Set the READY pin low) when the 6809 has control. I have some spare pins on the EEPLD for this if necessary.
5. I am not 100% convinced about my clock logic yet...
6. I am even less convinced about my memory mapping scheme! OK with the 6502/6809 part - but not how it will work with NitrOS-9 Level 2.
7. I need to add some more decoupling capacitors and tidy up the schematic accordingly.

It is a little late in the UK at the moment - so I am sure when I review the printed schematics tomorrow I will have some comments of my own...

I will also describe my memory mapping scheme in detail when I have had a good nights sleep.

Dave
 
Keep up the good work.

I'm thinking of converting my 4032 over for this. I've already got 3 6309's laying around that I bought to upgrade cocos.

Later,
dabone
 
daver2 said:
There are some DRC errors on unused pins of the EEPLD (Atmel ATF1508AS for the glue logic).
Click to expand...

Dave,
Wow, we are going high tech. Will you be using the 84 pin PLCC or the 100 pin PQFP pin package? I hope these won't be too hard to solder. Or is there some kind of handy socket available that will make life easier to solder the board? I guess you will bring out the JTAG ISP pins to a header to allow easy on-board programming using the free Atmel software?

This is going to be an amazing project.
-Dave
 
Dave,

The 84 pin PLCC has enough pins to do the job. The plan is to use a socket for the beast - so the pins will be on a 0.1" pitch for the PCB (nice and easy to solder). See http://uk.farnell.com/multicomp/mc-84plcc/socket-plcc-84-pin-thru-hole/dp/2097218 for an example of a socket.

I'll be bringing out the JTAG pins to a small header yes.

The use of this device has made the 'glue logic' and the PCB much easier. I have kept all the flip-flops and latches external (so the BANK SELECT and SYSTEM latches are still 74LS273s for example). The EEPLD should just contain combinatorial logic. It also means I can make the odd error or two and maybe get away with it by reprogramming the EEPLD!

Dave
 
daver2 said:
The use of this device has made the 'glue logic' and the PCB much easier. I have kept all the flip-flops and latches external (so the BANK SELECT and SYSTEM latches are still 74LS273s for example). The EEPLD should just contain combinatorial logic. It also means I can make the odd error or two and maybe get away with it by reprogramming the EEPLD!
Click to expand...

Excellent design decisions. If there will be some extra real estate on the board, a row of test point plated through holes on 0.1" centers will make hooking up a logic analyzer much nicer. It would be optional for the user to add the header to utilize the test points. One can then interface with a ribbon cable connector or clip-on test leads, etc.
-Dave
 
Just finished the updates to the schematics for the evening. I managed to incorporate all the changes I wanted to do. No DRC errors :). That doesn't mean it will work though! I need another nights sleep and will be super critical of my work tomorrow!

Good suggestion regarding test points though. That's going to be my next learning curve with KiCAD - footprints and the PCB layout tool...

No time left to document my MMU strategy though. I will post tomorrow...

Dave
 
Last edited:
Schematics finished and footprints added for all components. I now have a "rats nest" to sort out in the PCB layout tool! I have also identified most of the components I need from Farnell / Element14.

Unfortunately, work calls this week - so I will review my schematics for errors or stuff I should have done.

I promised a description of my Memory Management scheme. Sorry that this is a bit of a "brain dump" but here goes for comments:

SuperPET2 – Memory Management Strategy.

Revision : 1

Date : 21st February 2016

Author : Dave Roberts

The standard PET 8032 Memory Map

$0XXX – 4K RAM
$1XXX – 4K RAM
$2XXX – 4K RAM
$3XXX – 4K RAM
$4XXX – 4K RAM
$5XXX – 4K RAM
$6XXX – 4K RAM
$7XXX – 4K RAM 8*4K = 32K RAM in total.

$8XXX – Screen RAM (not fully populated).

$9XXX – ROM expansion area (unused in a standard 8032).

$AXXX – ROM expansion area (unused in a standard 8032).

$B000 - ROM
$C000 – BASIC ROM
$D000 – BASIC ROM
$E000 – Editor ROM and I/O area (from $E800 - $EFFF)
$F000 – Kernel ROM

Standard PET 8032 I/O devices

$E810 - $E81F – PIA #1
$E820 - $E82F – PIA #2
$E840 - $E84F – VIA
$E880 - $E88F – CRTC

SuperPET ROM

$AXXX
$BXXX
$CXXX
$DXXX
$EXXX – Shared with PET I/O.
$FXXX

SuperPET additional I/O devices.

$EFE0 - $EFE3 – 6702 Dongle
$EFF0 - $EFF3 – ACIA
$EFF8 - $EFFB – System Latch.
$EFFC - $EFFD – Bank Select Latch.
$EFFE – $EFFF – ROM/RAM in $9XXX

What does my SuperPET2 look like?

When in 6502 mode you have access to the same memory and I/O map as a Standard 8032 PET plus some additions for the SuperPET:

• The ACIA serial port ($EFF0 - $EFF3).
• The System Latch ($EFF8 - $EFFB).
• The Bank Select Latch ($EFFC - $EFFD).

I have removed the ROM/RAM latch ($EFFE - $EFFF) as my add-on board doesn’t support user ROMs.

I have also replaced the 6702 dongle with an SN74LS610 Memory Mapper Unit. This is mapped into I/O addresses $EFE0 - $EFEF (16 registers).

The 512K RAM memory of the SuperPET2 is utilised as Bank Switched memory into PET address $9XXX (exactly as the original SuperPET). Only the lower 64K of the 512K available is used in this Bank Switching mode.

The 6809 ROM is mapped out and the Standard PET ROMs are active.

The Write Protect switch will permit the Bank Switched memory mapped into $9XXX to be Read/Write or Read Only (depending upon the position of the switch or under software control).

When in 6809 mode everything is pretty much the same - except that the Standard PET ROMs are replaced with the Waterloo ROMs.

What is this MMU thing?

The MMU permits logical to physical address translation to occur in 4K pages. The physical address space of the 6502 and 6809 is limited to 64K (16 pages of 4K). Each page of 4K has a corresponding entry within the SN74LS610 MMU (hence the reason there is 16 registers within the I/O range $EFE0 - $EFEF).

The Standard PET 64K memory address is considered as 16 logical pages of 4K from $00XXX to $0FXXX. The 512K of on-board RAM is treated as 128 pages of 4K from $00XXX to $7FXXX. However, not the full 512K of additional memory is available because of the presence of the PET’s 64K (so in reality 512-64 = 448K of additional RAM is available).

So, how would we use the memory management unit?

The MMU is enabled by setting bit 4 of the Bank Select Latch to a ‘1’. However, just setting this bit (without initialising the MMU itself) will almost certainly cause a crash, as the complete memory map will be screwed up!

If we initialise the MMU registers as follows:

MMU Register $0 = $00.
MMU Register $1 = $01.
MMU Register $2 = $02.
MMU Register $3 = $03.
MMU Register $4 = $04.
MMU Register $5 = $05.
MMU Register $6 = $06.
MMU Register $7 = $07.
MMU Register $8 = $08.
MMU Register $9 = $10.
MMU Register $A = $0A.
MMU Register $B = $0B.
MMU Register $C = $0C.
MMU Register $D = $0D.
MMU Register $E = $0E.
MMU Register $F = $0F.

Then upon setting the MMU to enabled – the physical memory of our 6502 or 6809 will be pretty much as per a Standard 8032 PET. Notice that all of the MMU registers have been initialised with $0X with the exception of $9.

Recall that on a standard 8032 PET - $9XXX was unused. This 4K ‘hole’ was occupied by one page of additional RAM of the 64K on the SuperPET. When the MMU is enabled, however, I can’t use the memory for both Bank Switched memory and MMU also shared with the MMU (that would make the logic horrendous). So the page at $9XXX can be filled with one of the 4K pages from our available 448K. Hence the reason the higher nibble has been set to a $1. We could have used any number from $10 to $7F (corresponding to one of the 112 pages of additional RAM).

Note that when the 6502 processor is running – the Standard PET ROM is mapped in. When the 6809 processor is running – the Waterloo ROM is mapped out. This is because the Bank Switched memory has effectively ‘disappeared’ from the SuperPET and the Standard Waterloo ROM wont know how to use the MMU. It is also considered that in this mode we will probably want to run something like NitrOS-9 – so mapping the ROM out will be advantageous.

However, if we have just mapped the 6809 Waterloo ROM out – what are we executing? We have to load a ‘bootstrap’ program from disk into RAM and run that. This bootstrap program will initialise our MMU, perform the MMU switch (which will MAP out the ROM), possibly relocate itself and finally boot whatever operating system we plan to use. Sounds simple!

One trick to watch however is where we are executing when the MMU is enabled. If we are running out of the Standard 8032 PET memory (and we have initialised the MMU as shown above); then everything ‘should’ work as planned as the same memory will be at the same address both before and after the MMU is enabled. If not, we have got problems!

Once the MMU is up and running – we can play around with where the PET’s memory map appears. So (for example) we could move the PETs screen from $8XXX to $DXXX by setting up the MMU registers as follows:

MMU Register $D = $08.

MMU register $D effectively translates (in English) to the 4K processor address page $DXXX. The $08 means PET Standard memory $08 and page 8.

We could also map the screen completely out of memory if required (replacing it with RAM) - only mapping it back in if the 'screen driver' wishes to update the screen.

Note that PET page $EXXX has to be mapped somewhere within the 64K - otherwise we couldn't have access to the I/O page to update the MMU registers themselves and we have completely 'snookered ourselves' with no way of recovering!

I am using the trick appropriated (a.k.a. stolen) from the TPUG MMU for running OS/9. This scheme ‘forces’ address $9XXX onto the PET 8032 address lines during a RAM access that is not from the standard PET memory map. However, the use of a MMU device on my add-on board has meant that I can make the addressing scheme more comprehensive.

The MMU registers are 8-bits and I have only described setting them with the values $00 to $7F. I have decided to use the most significant bit as a write protect bit for the selected page. Any attempt by the processor to write to a 4K page that has the MMU top bit set will cause the transfer to not work. I am just thinking whether this should cause an FIRQ if the 6809 processor is running?

It may be too difficult to handle this for writing to the Standard 64K of PET memory – but I will think about this later.

Note that with the MMU enabled, the write protect switch of the standard SuperPET will be inoperative.

I think that’s a bit of a brain dump – so I might have got things completely wrong somewhere. The next thing to think about is “will my proposed MMU scheme work with NitrOS-9”?

Comments anyone?

Dave
 
Last edited:
I am having second thoughts after re-reading my own post today.

I think I am adding complexity where none is required by incorporating a feature within the MMU for write-protecting each 4K page.

I think I will revert back to the idea of not bothering with the write protect feature and use the extra bit from the MMU register as an address line. PET memory will be accessed by setting the MMU register(s) up to $00 through to $0F. Values in the range $10 through to $7F will be undefined. Values in the range $80 through to $FF will address a 4K page in the 512K of static RAM. I can (therefore) fully utilise the RAM by using this MMU register decoding mechanism - and can use the 'undefined' pages from $10 through to $7F for memory expansion to just under 1 MB in any future (mark 2) enhancement to my SuperPET2 board...

Dave
 
daver2 said:
I think I will revert back to the idea of not bothering with the write protect feature and use the extra bit from the MMU register as an address line. PET memory will be accessed by setting the MMU register(s) up to $00 through to $0F.
Click to expand...

Having a Memory Management Unit (MMU) in a Commodore PET is still boggling my mind a little.

Will one be able to power up in the 8032 PET mode or the 6809 SuperPet mode with a throw of a switch, or will things be a little more complicated? I'm sure that you will see to it that everything is compatible with the existing Waterloo System disk, etc.

Respond only when you get some free time, no hurry.
-Dave
 
Yep.

The SuperPET has two switches. One selects the processor and the other selects whether the SuperPET memory is write protected or not. Let's ignore the write protect switch for now and concentrate on the CPU switch.

This switch has three positions - 6502, 6809 and software programmable. The first two switch settings (6502 and 6809) should be obvious. The 'software programmable' setting does what it says on the tin and you can POKE to the SYSTEM LATCH ($EFF8) to select which processor you require (bit 0). If you leave the switch in 'software programmable' mode - power-up will select the 6809. You could then run a small noddy program to 'flip' back into the 6502 PET mode. Flipping the physical switch from 6502 to 6809 (or vice-versa) will cause the processor to change and a RESET to be invoked. As simple as that...

The MMU will not affect the operation at all until you activate it by writing a '1' to bit 4 of the BANK SELECT LATCH ($EFFC). This is similar to how the TPUG MMU works for OS-9 (see http://mikenaberezny.com/hardware/superpet/super-os9-mmu/ for more details).

I agree - MMU operation can freak you out... Imagine how my poor brain feels trying to design it (and I am still not 100% confident that it will work yet)! QDOS to the guys at TPUG though with coming up with their clever design. Their design kickstarted me into thinking that a more comprehensive scheme was possible.

Hope that answers your question?

Dave
 
daver2 said:
Yep.

The SuperPET has two switches. One selects the processor and the other selects whether the SuperPET memory is write protected or not. Let's ignore the write protect switch for now and concentrate on the CPU switch.

This switch has three positions - 6502, 6809 and software programmable. The first two switch settings (6502 and 6809) should be obvious. The 'software programmable' setting does what it says on the tin and you can POKE to the SYSTEM LATCH ($EFF8) to select which processor you require (bit 0). If you leave the switch in 'software programmable' mode - power-up will select the 6809. You could then run a small noddy program to 'flip' back into the 6502 PET mode. Flipping the physical switch from 6502 to 6809 (or vice-versa) will cause the processor to change and a RESET to be invoked. As simple as that...

The MMU will not affect the operation at all until you activate it by writing a '1' to bit 4 of the BANK SELECT LATCH ($EFFC). This is similar to how the TPUG MMU works for OS-9 (see http://mikenaberezny.com/hardware/superpet/super-os9-mmu/ for more details).

I agree - MMU operation can freak you out... Imagine how my poor brain feels trying to design it (and I am still not 100% confident that it will work yet)! QDOS to the guys at TPUG though with coming up with their clever design. Their design kickstarted me into thinking that a more comprehensive scheme was possible.

Hope that answers your question?

Dave
Click to expand...

Dave,

How are things progressing? I'm eager to see this finished! The last few months I've been learning Kicad and have created about a dozen various schematics, successfully created 3 PCB's, and routed several more waiting to get made. If your design is finished and you just need to route it, I would be able to help. I have a few hours each day I can work on it.

Steve
 
I don't know about Dave, but I offered to help as well, and Dave and I have exchanged files and such, but Summer has sucked up a lot time already. My weak point is KiCAD, so maybe you should have a go at routing it (I moved it to EAGLE to route, and am partially done routing, but not done, by any means)

My question to Dave was about the MMU. It's a tough part to find and so I had some questions (I like the idea, but wondered if it other options should be considered.

Jim
 
Here's a clone of the PEDISK board a group of us just finished:

http://www.6502.org/users/sjgray/projects/pedisk2/index.html

I entered the schematics into Kicad and manually routed it first to match the existing traces as close as possible, and then after moving the rom and eprom up and adding additional mounting options I had to re-route about 1/3 of the traces. I imagine a superpet board will be about 3-4 times more complicated but I'm pretty sure I can do it.

Steve
 
I’m going to offer an unsolicited opinion regarding the design philosophy I would think best for a project like this one. Feel free to ignore it, especially since the viewpoint I am about to promote (when combined with my unfortunate tendency to “perfectionism ad absurdum”) has resulted in my having never actually completed so much as a single one of the numerous retrocomputing-related projects which I have nominally begun. Anyway:

This thread initially grabbed my attention with its apparent premise, “devise an expansion board to make a stock PET/CBM 8032 into a pseudo-stock SuperPET.” (Shall we call such a result a "PseuperPET?") Because pretty much all of us in this hobby except the most dedicated preservationists like to stretch the limits of the possible, a fairly obvious secondary goal almost immediately arose in the discussion, which we might frame as “let’s add cool features while we’re in there!”

I think there are a lot of design points that are important enough to be default requirements for this sort of thing. Here are four of them:

(1) Must replicate the original functionality, if not necessarily the original design. The currently-proposed implementation would be significantly incompatible from a software point of view—at a minimum, any attempt to run an unmodified copy of the Waterloo software on it would fail miserably because the MMU mapping registers are present where it would expect to find that silly copy-protection dongle (a 6702 chip, I think it was?); OTOH, the idea of bus-isolating the 6502 correctly, or at least less incorrectly, makes a lot more sense than the original design does. I agree in principle with leaving out the dongle function (too much trouble for far too little benefit), but I see no way for putting unrelated, new functionality in the exact same address locations to possibly end well. The Waterloo packages might well fail far more spectacularly than expected, and future software intended specifically for the PseuperPET would likely go quite gruesomely awry when run on a real one; algorithms meant to include MMU manipulations seldom do anything benign (or safely) when applied instead to totally unrelated hardware!

Also under this point, as others have already noted, the initial suggestion to completely omit the ACIA would have sufficiently compromised the board's compatibility with period software as to noticeably curtail the usefulness of the end product.

(2) Must be, if not actually an elegant design, at least sufficiently self-contained (and of course non-destructive, though that at least hasn't thus far been much of a concern here) as to resemble it upon casual inspection. The idea of needing a separate flying lead to inject a 4 MHz clock really does not qualify either way. While such would not unduly complicate board installation for us techie types (who probably make up 99 percent of the target market in the first place), it would necessarily look a bit clumsy, and I have picked up a vague background impression from past experience that such a long, relatively high-frequency signal lead might be subject to messy enough EM interference issues as to be decidedly suboptimal from the outset.

(3) Must specify component parts which are readily, inexpensively available, and highly likely to remain so. This aspect, if not yet all of the others, seems to be going very smoothly so far.

(4) Design enhancements added in pursuit of the second overall goal must not be of such magnitude as to make the intent ("make it possible for many more people to enjoy a SuperPET than is currently the case") behind the first goal obsolete. I note that once the possibility of running, e.g., a modern port of NitrOS-9 on the new board was proposed, it immediately became a design assumption that 512KiB of SRAM would be a good number to plan around. While having more RAM is rarely inherently a problem… is adopting a design requirement that all but outright excludes original hardware from benefitting from such an OS port really consistent with what was originally wanted? It looks to me like this thread is currently headed into the embarrassing territory of needing to start a second design project to upgrade or replace vintage TPUG MMU boards, so they could work the same way as the PseuperPET's onboard version. A SuperPET is a specific concept, as is the original idea in this thread. Turning this design into a, basically, functionally unrelated machine housed in a similar case is not enormously different from just taking out your 8032's system board entirely and sticking a maxed-out CoCo 3 in there instead. Would that really be consistent with the original intent?
 
> I am about to promote (when combined with my unfortunate tendency to “perfectionism ad absurdum”) has resulted in my having never actually completed so much as a single one of the numerous retrocomputing-related projects which I have nominally begun.

I'm coming back to this after over a year since I recall being involved in email correspondence with parties about this concept
in January following the creation of this thread, which I was unaware of at the time.
Contrary to the eloquent and humble disclaimer, the above suggestions sound like the voice of reason to me.
 
Thanks for all the feedback guys - I have been reading it and thinking...

At the moment work is somewhat hectic - and I have just taken on a project of refurbishing a PDP 11/45 so that has taken a bit of a higher priority on my list for the moment.

The original concept of this project was an add-on board for a standard Commodore PET 8032 to turn it into a SuperPET by the addition of a small card in place of the 6502 CPU - but using more modern components. The project was to be 'free' in terms of the PCB details would be published - along with a Bill of Materials etc. for home/hobbyist assembly.

The perceived target was existing owners of a Commodore PET 8032 with sufficient hardware skills to procure the necessary parts, build their own card, install it in their PET and debug the resultant system.

What I was going to get out of the project was (a) a board I wanted - I always fancied a SuperPET and (b) to extend my skills to produce PCBs using modern tools. To this end - I was looking to use the free KiCad tool.

I must admit - the thought of enhancing the card to be able to run NitrOS-9 was tempting and (as has been said) perhaps this has overrun the project too much.

I had the schematic designed but was having a few problems with the PCB layout. Jim kindly offered to convert the KiCad project into Eagle and undertake the layout himself. A few e-mails later and I was wondering where the project was heading myself.

So (to cut a long story short) the comments on this thread have been quite timely!

Taking gsteemso's points in order:

(1) Any attempt to run the '6702 dongled' Waterloo software on my add-on card would result in a miserable failure anyhow. All of the Waterloo languages look for the presence of the 6702 and die a horrible death if it isn't found. I was part of the team that added the SuperPET functionality to VICE. I was also part of the team that 'disassembled' the functionality of the 6702 and I was the person who removed the 6702 protection from the Waterloo language disks (see http://mikenaberezny.com/hardware/superpet/waterloo-languages/). There are no plans to add 6702 functionality to the add-on card. Knowing the Waterloo software to 6702 interface pretty intimately - I can be pretty sure that there should be no unintended interaction between the software and an MMU occupying the same addresses. I take on board the comments regarding running software for the SuperPET2 on a real SuperPET though...

(2) The original (Mk I) SuperPET used the standard 6502 Phi0 clock and generated the quadrature clock for the 6809 on-board. The later (Mk II) SuperPET board used a 16 MHz clock that was fed to the card via a track on the 8032 main board (and a No Connect pin on the 6502 CPU). I did think the Mk II SuperPET design more elegant - but decided to go with the clock circuit as recommended in the 6809 data book (requiring a 4 MHz clock instead of the 16 MHz clock to keep the frequency as low as possible). I did add the option of using the same NC pin on the 6502 CPU for people wishing to modify their main board by the addition of a wire link or via a flying lead. I would be more than willing to go back to the original idea of using the Phi0 CPU clock - which should work with every 8032 main board in an unmodified form.

(3) Agreed. This was a potential flaw of using the MMU (it is obsolete already - although I have found a reasonable stock of 70 of these items) - and a CPLD. If I was assembling a card - I would prefer all my components to be through-hole. Jim was proposing the use of surface mount components and a more complex programmable device incorporating more if the logic internally - which I was starting to feel uncomfortable with.

(4) Agreed. This may have "run-away from me a bit here"!

Proposal going forwards:

(1) KISS - Keep It Simple Stupid!

1a) WDC65C02 CPU.
1b) 6809 CPU.
1c) Single OTP EPROM incorporating Waterloo SuperPET firmware.
1d) Single RAM chip. I can see 128K*8 or 512K*8 available. I can't see 64K*8 available (from Mouser at least). Both the 128K and 512K devices are in a 32-pin DIP. I am leaning towards the 512K*8 at this point in time.
1e) 6551 ACIA with RS232 buffers.
1f) Reset circuitry - 74LS123 as per the original SuperPET.
1g) All devices through-hole.

(2) Outstanding issues:

2a) Clock circuit. Should I use the original 6502 CPU Phi0 clock - and generate the 6809 'Q' phase via 74LS123's? This should make the SuperPET2 add-on board fully compatible with every 8032 without any modifications.

2b) With the simplification of the project (!) this should permit most (if not all) of the 'glue' logic (e.g. address decoding etc.) to be incorporated into one or two PAL/GAL devices instead of a CPLD. Would this be considered sensible?

2c) With a reduction in the logic (and the move to CMOS memory and 6502 CPU devices) this should permit the 5V power rail to be obtained via the 6502 CPU socket instead of a flying lead. Comments?

I have currently copied my KiCad SuperPET2 project to one called SuperPET3 (!), removed the MMU and pretty much tracked up the remaining components. The main outstanding issues at the moment are the clock circuit and the address decoding 'glue' logic as per 2a and 2b above.

Thoughts and comments?

Thanks for your constructive feedback.

Dave
 
daver2 said:
(2) Outstanding issues:

2a) Clock circuit. Should I use the original 6502 CPU Phi0 clock - and generate the 6809 'Q' phase via 74LS123's? This should make the SuperPET2 add-on board fully compatible with every 8032 without any modifications.

2b) With the simplification of the project (!) this should permit most (if not all) of the 'glue' logic (e.g. address decoding etc.) to be incorporated into one or two PAL/GAL devices instead of a CPLD. Would this be considered sensible?

2c) With a reduction in the logic (and the move to CMOS memory and 6502 CPU devices) this should permit the 5V power rail to be obtained via the 6502 CPU socket instead of a flying lead. Comments?
Click to expand...

Hi Dave,
2a) The clock circuits in both the original and combo SuperPet boards seem suspect and do not seem to meet the 6809 specification for timing relationship of signals E and Q. We may need someone to get us photos from a scope or logic analyzer. In the first case, the Q seems inverted or I missed an inverter somewhere. Also I hate One Shots in critical clock circuits. The 74123 was the worst Monostable device ever made and can be re-triggered with noise. A lot a space is needed in the layout of the RC networks to prevent crosstalk triggering. A Fairchild 9602 is a better choice if a One Shot must be used as it has good hysteresis. I like the combo board clock design better. It uses a shift register clocked at 16 MHz to create a synchronous "tapped delay line" for the Phase Zero clock with a resolution of 125 nS per tap. Even here the combo board seems to use the wrong tap. It looks like a delay of 375 nS rather than 250 nS. The 6809 spec says 200 nS min and 250 nS max. I understand the reluctance to route a 16 MHz clock between boards.

2b) I like the PAL/GAL22V10 devices, but I bet it would take more than two to sweep up all the glue parts. Of course if the board were made bigger then the number of PALs would not be an issue.

2c) I didn't realize you intended to steal +5V from the main board rather than use a separate regulator. We better perform a power analysis before we finalize the design. I think the PET only has a 1A regulator.

Overall, you are on the right track. You are making great progress!
-Dave
 
Dave,

Thanks for the encouragement...

2a)

I agree with what looks like an 'accidental' (read Commodore deliberately introducing an error onto the schematic) inversion if the 6809E 'Q' input. The falling edge of 'E' should trigger a high-going output pulse on U2/13. The falling edge of U2/13 should trigger a high-going pulse on U2/5 and a low-going pulse on U2/12. I agree that the 6809E 'Q' input should be sourced from U2/5 (Q output).

I agree with your thoughts on the clock circuitry for the MK I SuperPET - but it did work, was simple and should work with all 8032s. We can always tweak the C/R network values bit later to get the correct timings. Shall I assume we are going that way and update the schematic and PCB layout accordingly? Interestingly, I am just placing an order for 800 off Fairchild 9602's for a job at work... I wonder if we may have some left over?

2b)

Looking at the logic tonight. Found an interesting difference between the Mk I and Mk II SuperPETs that someone could help out with.

The chip select logic for the ACIA seems to work out OK from $EFF0 ... $EFF3.

The chip select logic for the SYSTEM_LATCH seems to work out OK from $EFF8 ... $EFFB.

The chip select logic for the BANK_SW seems to work out differently. On the Mk I SuperPET it decodes from $EFFC ... $EFFF. On the Mk II SuperPET it decodes from $EFFC ... $EFFD with the ROM/RAM port (which doesn't exist on the Mk I SuperPET) decoding from $EFFE ... $EFFF. I don't have a ROM/RAM latch on my implementation - so I plan to decode the BANK_SW latch from $EFFC ... $EFFF. Any observations - or should I add A1 into the mix and decode for $EFFC ... $EFFD to be on the safe side?

I am trying to keep the number of PALs to a minimum...

2c) It was just a thought. I started to have a look at the power consumption and realised that the data sheets I have are not particular good when it comes to the current consumption parameter. I shall add a +5V 7805 Voltage Regulator on the card and some associated decoupling fed from the +9V unregulated line. In series with a 1N4001 diode for protection? An on-board power available LED?

Incidentally, I decided to go for a 512K * 8 SRAM in the end. There was an additional active-high chip select line on the 128K * 8 equivalent. I have tied the unused address lines to ground for the time being. They could be wired to the 3 unused outputs from the bank switch register if desired (although this will introduce a difference between the SuperPET and the SuperPET2).

Dave
 
Last edited:
You must log in or register to reply here.
Back
Top