Announcement

Collapse

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    Originally posted by daver2 View Post

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

    Comment


      #47
      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 by daver2; February 20, 2016, 01:06 PM.

      Comment


        #48
        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 by daver2; February 21, 2016, 11:51 AM.

        Comment


          #49
          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

          Comment


            #50
            Originally posted by daver2 View Post

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

            Comment


              #51
              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 ($EFF 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/su...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

              Comment


                #52
                Originally posted by daver2 View Post

                Hope that answers your question?
                Dave,
                Absolutely, yes. Good work! Let us know how we can contribute when it come time to buy software tools or PCB prototype fab.

                -Dave

                Comment


                  #53
                  Originally posted by daver2 View Post
                  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 ($EFF 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/su...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
                  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
                  WANTED: CBM-II hardware or software, PET software

                  Comment


                    #54
                    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

                    Comment


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

                      http://www.6502.org/users/sjgray/pro...sk2/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
                      WANTED: CBM-II hardware or software, PET software

                      Comment


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

                        Comment


                          #57
                          > 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.
                          http://abitoutofplace.wordpress.com/

                          Comment


                            #58
                            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/su...loo-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

                            Comment


                              #59
                              Originally posted by daver2 View Post

                              (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?
                              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

                              Comment


                                #60
                                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 by daver2; July 6, 2016, 11:02 AM.

                                Comment

                                Working...
                                X