Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.

Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.

Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.

Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.

Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.

Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.

Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.

New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.

Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Commodore 8032 add-on board - SuperPET

  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by daver2 View Post


    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.


    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...



        Originally posted by daver2 View Post
        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.



          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.




            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.




              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 20V.

              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...


              Last edited by daver2; July 9, 2016, 08:33 AM.


                Originally posted by daver2 View Post
                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.


                  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.



                    Originally posted by daver2 View Post

                    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.
                    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.


                      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.
                      the world’s only gsteemso
                      agitator-in-chief for the Seattle Retro-Computing Society


                        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.




                          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)


                              Originally posted by theslownorris View Post
                              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 - you can contact Dave Stevenson

                              WANTED: CBM-II hardware or software, PET software


                                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!