• Please review our updated Terms and Rules here

Commodore 8032 add-on board - SuperPET

2a)

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?

Yes, OK, clock circuit should work.

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 Mk1 implementation should suffice.

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

It might pay off to leave an extra PAL footprint available to correct any 'oops' in the design. A small 20 pin GAL 16V8 gives flexibility to fix anything that might come up. Or perhaps leave a GAL with six spare pins.


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.

Look for an Electrical Parameter called Icc (max). That is a good worst case number for the device current.
 
So - tonight's activity was to create the initial logic files for the two 16V8 PAL devices (U81 and U82).

U81 takes a load of address lines (A15..A4) and decodes for addresses matching 9XXX (the bank switched RAM) and EFFX (the additional SuperPET I/O devices). These two signals are passed to a second PAL (U82) where we have a few of the lower address lines (A3..A1), RnW, PHI0 and BIT7 (from the system latch) and decodes for the ACIA port selection, The BANK SWITCH port selection and the SYSTEM LATCH port selection.

I currently have 4 spare pins on U81 (I/O) and 8 spare pins on U82 (3 I + 5 I/O).

Next, I am working on the decode logic for the EPROM and RAM...

Dave
 
So - tonight's activity was to create the initial logic files for the two 16V8 PAL devices (U81 and U82).

When you are ready to publish the equations, I will be glad to generate some test vectors so we can simulate the design on PALASM4 and/or Wincupl and later the vectors will be part of the JEDEC file and will be used to functionally test the parts during the verification step that occurs after programming.
 
Dave,

I have just finished the equations for two of the PALs (decoding the ROM, system latch, bank latch and ACIA and partial decode of the RAM). I will check them over tomorrow for dumb errors and spooling mistakes in the comments and post them for you to critique. It is getting a little late in the UK and I am sure I will miss something obvious if I post them tonight!

I have had to add a third PAL (RAM decoding and miscellaneous). I could have 'shoe-horned' the logic into the two PALs - but I thought better of it and plan to leave a few spare pins on each PAL as you have suggested. I will work on the logic for this third PAL over the weekend.

Dave
 
Dave,

Designing for 16V8 is OK. We can always switch to the PAL/GAL 22V10 if there is need to sweep-in additional glue circuitry. There is almost no space penalty, as the 22V10 is a 24 pin skinny DIP (0.3") vs 20 pins for the 16V8. Both parts are still being produced by Atmel I think. I have several tubes of both Atmel parts. I also have quite a few AMD 22V10's squirreled away. They are the older UV window type rather than the newer electrically erasable, but are quite fast enough for the PET logic. I have a programmer for the Atmel parts as well as an ancient Data I/O 29B for older parts. I would donate programmed PALs to anyone building your SuperPet board.
-Dave
 
View attachment TODAVEM1.zip

Dave,

Please find attached my first attempt at three 16V8 PALs for the SuperPET2. I have no problem with them being upgraded to 22V10s - it is just that my programmer won't program those devices (I can do 16V8 and 20V8).

I have found a couple of issues that I could do with some peer review on however:

1) The clock (PHI0 or PHI2) is not included within the decoding of the ROM (see U82). I can't see this being much of a problem however.

2) The reset logic between the SuperPET MK I and II is different. In the MK I the PET_RESET resets the ACIA and SYSTEM LATCH and feeds into a couple of AND gates (U5/8 and U5/11) where the signals from the /Q outputs of the two reset monostables are gated with the PET_RESET to form a common reset for the two CPUs and and the BANK SWITCH latch. In the MK II, the system latch is reset via a power on reset only (comprising a CR network). There seems to be an additional reset signal from one of the reset monostables (U12 via transistor Q1) driving the PET_RESET line. My guess is that when the CPU selection switch is changed from 6809 to 6502 - this forces a reset of the devices on the PET main board. What are peoples thoughts about whether I should implement what is on the MK I or MK II SuperPET boards? My U83 PAL implements what is currently on the MK I board for information.

I am on a business trip this week - so I will have a look at the power budget whilst sitting in the hotel...

Cheers,

Dave
 
Last edited:
Please find attached my first attempt at three 16V8 PALs for the SuperPET2.

These equations look very straightforward. We should have no issue with them. Later we'll need to see the complete schematic to see how the GALs fit in, but so far so good. I'll generate some test vectors for the outputs we have so far.
-Dave
 
Hi Dave,

Welcome back - have you been on holiday/vacation?

I didn't think they were rocket science...

What do you think - go with two 22V10's for the logic I have done (I may use a couple more outputs to get rid of the O/C buffer and (possibly) the inverter package I have to keep the part count down a little bit) and a 16V8 for spare? I will still keep a few I/O pins on the other 2 devices as spares as well if I can.

I can then get on with the clock generation logic and the programmable logic on the schematic. Issue that so people can see what I have done. And then track up what's left.

Dave
 
What do you think - go with two 22V10's for the logic I have done (I may use a couple more outputs to get rid of the O/C buffer and (possibly) the inverter package I have to keep the part count down a little bit) and a 16V8 for spare? I will still keep a few I/O pins on the other 2 devices as spares as well if I can.

Dave,
Yes, if you're thinking of possibly sweeping more stuff into the PALs, then two 22V10's would be a better choice. I'll find out how many I have. I'll offer parts and programming gratis for anyone building your board.

I converted the U81 16V8 file to run with the syntax of my old AMD PALASM4 and it assembled and output a JEDEC file with no errors. I may wait to generate the test vectors until the design is finalized so I don't miss any signals we may add.
-Dave
 
Looks pretty good overall. If your board doesn't have the extra switch that requires also decoding A1 in that addressing block, I see no reason to bother doing so; it sounds like some period hardware also did not bother with that, so it shouldn't introduce any compatibility concerns that were not already present 30-odd years ago.

The idea of linking the bonus addressing lines on the modern SRAM chip to otherwise unused and useless bits in the banking control register (or whatever it was called) is not inherently evil. While that minor design change would cause a very slight behavioral difference and in theory might break some carelessly written software, I do not see that as being a genuine problem. The secondary goal here, if you happen to agree with my prior summary at least, IS to add cool features where they won't interfere with the primary goal of expanding the population of vintage PETs that can be used more or less interchangeably with genuine SuperPETs. (The "more or less" qualifier applies solely to the 6702 dongle-chip omission, which is rendered moot and thus ignorable by the recent posting of Waterloo software images edited to not check for it.) I suppose we will only be able to tell for certain that the change is indeed benign by running period software on an 8032 with the new card installed, or perhaps by making a minor modification to someone's local copy of VICE that would reflect the new behaviour… I personally wouldn't vote for that method as my first choice, though. Perhaps it is irrational of me, but I harbour a minor degree of paranoid mistrust of simulation-based testing for "fringe" platforms (i.e., those for which the emulator software has relatively tiny user bases). The hugely popular family of VICE C64 emulators? Thousands, maybe hundreds of thousands of users; very reliable. I'm certain there were never more than a few tens of thousands of original PET users even in aggregate, though, and if I had to guess, probably well under 5 percent of the original user base retain any interest in it today. Logically, it seems very unlikely that the corresponding VICE binary could possibly be as reliably accurate, simply due to it having been use-tested so much less extensively.
 
OK - so I have finished the next pass of the KiCAD schematic sweeping up the following:

1) I have updated the clock logic to follow the Mark I SuperPET schematic with the 74LS123 mono stables (ditto for reset logic).
2) I have added a 7805 +5V Voltage regulator - so we can feed the card +9V unregulated.
3) I have put four (4) GAL16V8 devices on the board. I part-use three of them - with the fourth as a 'no fit' in case I screw something up...
4) I may have given an incorrect description of the RAM in a previous post. I am using the 512K * 8 device - but only wiring four bank switch lines up (so a total of 64 KB). The reason for this is that the 128K and 512K have significant pin-out differences - so if I wanted to upgrade the board in the future I would have to do more PCB changes than I would like around the RAM area. Also (by using a 512K device) - they are more modern, the same price as the 128K device and they will probably be around for a bit longer that the 128K device.

I have found an error in the schematic just this morning - so I will hold on to the schematic for another week until I have had chance to look over it again for stupidities. I will also need to make a small change to the GAL logic (and I also found a bug in that as well today).

Dave (M) - if you haven't already, can you PM me with your private e-mail address and I will send you a PDF copy of the schematic and the updated GAL logic for review.

I will then have a go back at the PCB layout - incorporating the changes.

Cheers,

Dave
 
Dave,
Are you still working on development of the SuperPET board? Just curious, being an owner of a two board machine.
 
I second miraco here.

I have an 8296 missing it's daughter/ram board. Heck I'd just love to find a ram board. I have a few PET things that I just got my hands on so I'm on the look out. (Trying to get in touch with bitfixer here for an PetSD)
 
I second miraco here.

I have an 8296 missing it's daughter/ram board. Heck I'd just love to find a ram board. I have a few PET things that I just got my hands on so I'm on the look out. (Trying to get in touch with bitfixer here for an PetSD)


Nils Eilers has completed his SuperPET clone board. I have one but haven't had a chance to assemble it as I'm waiting for parts. I don't know if he's selling them yet to the public as there are some fixes required on the pcb, but you could contact him to see.

Bitfixer has PETDISK, not PETSD. For PETSD+ (by Nils Eilers - petsd.net) you can contact Dave Stevenson http://www.primrosebank.net/computers/pet/projects/pet_petsd_order.htm

Steve
 
Sorry, I missed these earlier posts.

No, I haven't got any further with it unfortunately. I got stuck with the PCB layout part of KiCad. Everything else was done.

Although it's good to hear from Steve that one is now available!

Dave
 
Back
Top