PAL-1 56K RAM/ROM expansion -- In development

[Jeremy Starcher]

I've been working on a new RAM/ROM expansion for the PAL-1 by cheating -- a lot -- and using my Raspberry Pi Pico to emulate RAM and ROM.

SO my current design plan was to not cheat and use all the regular glue logic to select what what address ranges are mapped into the PAL's bus.

I've got a 7400 for turning PHI2 and the WE into a WE enable for the "chip"

I've got an 74145 for address decoding

and I've got all 8 of the K lines on dip switches, so this can be mapped in anywhere, including the upper 8K that mirrors the bottom 8K.

The ROM part is working.  The RAM part is in progress but I have no doubt I'll be able to get it.

So -- here is the question:

Do people care if it is authentic? or if it just works?

If I drop the hardware glue logic and go for a 100% software based address decoding, I can drop all the chips off this board except for the Pico itself and I can make this thing tiny... like so tiny it might even fit inside the existing PAL-1 case.

RAM/ROM and the second timer on a little tiny board ...

Or would dropping the glue logic and dip switches break the "spirit" of the thing?

[Jeremy Starcher]

[Eduardo Casino]

Hi Jeremy,

Very nice!

I just sent a board to fabrication with a similar concept, but using a Pico W so it can be reconfigured on the fly, and covering the complete address map.

My thougths:

• I would go for an all-modern approach. considering that the Pico is already there :)
• I don't see any level shifting in your board. I don't own a PAL-1 (yet), but I understand that it uses 5V TTL levels, same as the KIM-1. In that case, sooner or later you'll fry the Pico. You'll need to add some 74LVC buffers for the input and I/O lines.

Again, very nice little board :) Just out of curiosity, are you using PIO?

Cheers,

Eduardo

--
You received this message because you are subscribed to the Google Groups "PAL 6502 computer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pal6502+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/5028cd32-f050-4659-80de-39b98c4aa184n%40googlegroups.com.

[GN Liu]

Hi Jeremy,

I think it depends on what you will use for the expansion.

If you want the expansion provide a stable and easy way to expand the existing capability of PAL-1, I think the all software way is to go, since Pico is powerful enough for this scenario and the fewer components the less issues.

If you want the expansion to give you some retro operating feel and look, the hardware switches and chips will help.

Best,

Liu

[Hans Otten]

As simple as possible! LEave out what is not necessary.

And yes, the 2040 is a bit 5V tolerant, but not 100% according to the RPi folks. Level shifters are advisble.

[Jeremy Starcher]

The level shifters are a debated topic on the Pico, I know. The data sheet says 3.3v.  The president of Raspberry pi says they can handle 5v but not 5.5v, so they can't be advertised as 5v tolerant.

In reality, a LOT of people are using them at 5v levels for retro RAM and ROM so they have a very good tract record of being used this way.

I have a compromise in mind, however.    I was going to keep that board itself without the level shifters, but instead, I would make a plug-in back plane that had the level shifters on it, in case I come up with another 3v device for to plug in. 

THT level shifters take a LOT of space... i have a prototype board that uses them.   Trying to avoid anything surface mount because not all PAL-1 lovers are ready for that level of soldering.

[Hans Otten]

RP2040 are indeed robust and cheap.  

As a compromise, I would put the RP2040 in a IC socket so it can be exchanged easy. 

[Jeremy Starcher]

I looked at using the Pico W but it didn't have enough pins free.  With this design, if I drop the glue chips, I am using every single free pin on the Pico /including/ pin 25 (LED).  I'd be curious to know what you are doing differently.

And no, not using PIO... turns out that is actually slower for this kind of application.

https://github.com/rhulme/picoROM_pio/blob/master/doc/README.md

Mind you, this was before I added a few more conditionals of checking for WE flags or checking address ranges, but those same checks would have to  be made on the microprocessor and not the PIO code anyways.

[Jeremy Starcher]

If I get the board I want in the end, it will be able to fit inside of the PAL-1 case... a socket would just make it way too big.

[Eduardo Casino]

I don't know why, but this message never reached the group. Resending, sorry if it duplicates. 

El vie, 8 mar 2024 a las 14:03, Jeremy Starcher (<jeremy....@gmail.com>) escribió:

I looked at using the Pico W but it didn't have enough pins free.  With this design, if I drop the glue chips, I am using every single free pin on the Pico /including/ pin 25 (LED).  I'd be curious to know what you are doing differently.

Just using 16 pins for addr, 8 for data, 1 for R/W and another to generate a CE signal to enable the data bus transceiver when an active area is addressed. The DECEN signal is generated with discrete logic using A13-A15 and CE. I'm not controlling K7 in this application, so the interrupt vectors must be present at the top of the emulated ROM.

I'm not syncing with 02, just trying to place and fecth the data to/from the bus quickly enough. 

 

And no, not using PIO... turns out that is actually slower for this kind of application. 

https://github.com/rhulme/picoROM_pio/blob/master/doc/README.md

Mind you, this was before I added a few more conditionals of checking for WE flags or checking address ranges, but those same checks would have to  be made on the microprocessor and not the PIO code anyways.

Thanks a lot for the hint! I'll try the pure C implementation.

Cheers,

Eduardo

To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/5b30378d-7893-4c97-9931-4e7b285eed3dn%40googlegroups.com.

[Jeremy Starcher]

Well...

The RAM is working and I successfully loaded BASIC into it and ran a few short programs... so that is in good shape.

Fun fact: If you have RAM filling the upper 48K of your KIM-1, but let the top 8K shadow the lower 8K -- bad things happen when Microsoft BASIC checks for available RAM.

It rolls through the 48K then it finds more RAM that just so happens to shadow the zero-page.

Then things go terribly wrong.

We won't talk about how long it took to me realize it was NOT a hardware problem...

[Eduardo Casino]

Congrats!

Very nice job, indeed. Stock frequency or does it need a bit of overclock?

[Jeremy Starcher]

I'm currently VERY overclocked -- but I don't know if I need to be.  The "PicoROM" project ran at a blistering 400MHz (according to the comments).

I figured I'd go ahead and run at that speed since everything stable and safe to do so, then I would start backing down the frequency once I got my code up and running.

The repo is a bit of a messy work-in-progress but you're welcome to look:

https://github.com/JeremyJStarcher/pal1-ram-rom

BTW -- it looks like I have enough pins that I can drop all of the glue logic entirely and handle the DEN entirely in software.  This means that I really should be able to to add a timer to this chip and get it working on everything but the extra I/O pins.

[Eduardo Casino]

Thanks!

I've come up with a similar solution, using 16bit words to deal with the non-contiguous pins :)

The main difference is that I use one of the unused bits to mark the address as available and another one to mark it writeable.

I'll share my repo as soon as the board arrives and test it working.

[Jeremy Starcher]

Ahah!

I just put in code to use one of the unused bits to check read-only! Great minds think alike.

I have a spare pin to go ahead and take over the DEN line so I may steal your idea of using another bit to flag it handled by the card.

BTW -- the board I posted there does not work. I have bodge wires all over mine as I am removing the various chips for routing.

[Jeremy Starcher]

I am planning on letting a person store "profiles" on the expansion card, so they can preload it with either ROM or RAM already configured (for example maybe having BASIC already loaded, etc.)

Added a simple control console for the Pico -- currently only accessible through the Pico's USB, but we'll see how that changes in the future.  This control console lets you upload paper tape files directly to the Pico RAM at blazing full speed...

863 CPS ... didn't take long at all to load BASIC.

[Jeremy Starcher]

Curious KIM-1 ROM bug.

If you request for a paper tape output all the way to FFFF, the paper tape routine stops a few bytes short.

Normally, nobody would have a sane reason for doing this, or even checking the results -- but when you are using that routine to test and debug address routing, it becomes slightly more interesting.

Ah well, I figure if the address routing works up to there that I can just not worry about the last 16 bytes.

[Jeremy Starcher]

Is this enough free space?

[Hans Otten]

That is lots of RAM!

[Jeremy Starcher]

The new version of the RAM/ROM board came in yesterday and, outside of one needed bodge, they are working well.

I've gotten rid of the 'glue' logic and the entire thing is now software controllable and you can set [almost] any region of memory as RAM or ROM, including overriding the RAM/ROM built into the PAL-1 itself.

(For instance, I am overriding the 3 bytes that store the string "KIM" so my serial terminal displays "PAL" instead.)

This way, via software, I can create an un-expanded PAL with the base 5K of RAM and the ram shadowing happing over 8K, to the full 60K of RAM or dropping ROM in at the normal spot.

There are also SIX different profiles that can be loaded and stored, though switching between them currently takes connecting to the USB port on the Pico itself.

I am looking at adding bank/profile switching from within the PAL itself, maybe writing to an un-used ROM location and then waiting until that value changes to show the currently loaded profile.

On the whole this is turning out quite nicely and I am learning a lot.

[Jeremy Starcher]

Alright, after reading and re-reading all of the info I could find, I decided that the board did, indeed, need level shifters on it, and the ones I liked most were outside of the range of what I could hand solder.

I just put in an order for the new boards, then I'll have to slightly  tweak the software to work with the new pin layout.

[GN Liu]

cool!

[Jeremy Starcher]

Latest update:

My new boards didn't work, level shifters were too slow, so I'm reaching out to try again with a different config.

I got the RIOT timer emulation working -- kinda.  Really weird.

First time you try it, it crashes the KIM-1.

Second time, it returns but gives the wrong value.

3rd time? Everything works like a champ.  Letting the test harness run for hours worked great.

[Eduardo Casino]

Hi Jeremy,

Try the 74LVC245 and 74LVC541. They have very low propagation delays and fast switchting even when powered with 3.3V and are TTL compatible. They work great in my design, I'm just having a bit of trouble polishing the PIO code, but that is another story.

You received this message because you are subscribed to a topic in the Google Groups "PAL 6502 computer" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pal6502/x87pdwzXedg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pal6502+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/8486b6e6-1ed8-4d98-9de3-f927b6a8b67cn%40googlegroups.com.

[Jeremy Starcher]

Try the 74LVC245 and 74LVC541. They have very low propagation delays and fast switchting even when powered with 3.3V and are TTL compatible. They work great in my design, I'm just having a bit of trouble polishing the PIO code, but that is another story.

Thank you, but I already looted your designs for good ideas ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/CAMYVxOikdXcV2cpmUnp1E-%3DThFUVO3%2BQLhLbmmVQmzJeks1%3D%3Dw%40mail.gmail.com.

[Jeremy Starcher]

RIOT timer emulation is reliably passing all of my tests.

Still waiting on the PCBs.

[Jeremy Starcher]

Quality of life improvement:

The input is forced to upper case. No beating away with th CAPS key and driving myself crazy.  I'll make that software switchable soon.

PCBs are shipping, hopefully these will work and everything will be grand.

[Neil Andretti]

Good morning Jeremy,

are there any new developments?

I really like to rebuild your interface with my humple possibilites, it looks just too promising.

Have a nice day,

Nils

[Jeremy Starcher]

Alright the current status is:

I have  basic version of the board, without any kind of level shifting, that works WONDERFULLY.

It can mimic RAM and ROM, including replacing all onboard RAM and ROM.. has some quality of life features like forcing TTY input to upper case, things like that.

However, since it is a 3.3v device on a 5v system -- its not "trustworthy."  I've done some research on the just how 5v tolerant the Pico is and applying 5v to the analog pins is ... more discouraged than applying 5v to the other pins.

I'm trying to get a version with the level shifts and/or bus controller up and running, but none of those have panned out for me as I expected, but I do have a new set of boards coming in next week.

If you don't mind taking the risk of using the pico in the un-level-shifted mode, I can provide the PCBs for that so you can experiment with things as you'd like.

The software is about 90% where I want it to be -- all of the major features are in place and they all work, but many of the features are currently compile time options.

I could either provide a few firmware files to copy on or you can build your own firmware if you are comfortable with Pico SDK development.

[Neil Andretti]

Moin,

I really like to give it a try, googled a bit and found this quote:

Eben Upton says:

September 25, 2022 at 4:16 pm

Note: the pads themselves are 5V tolerant for input, just not 5V5 tolerant, which is what we’d need them to be to put “5V tolerant” in the data sheet. (Hypothetical) future designs will fix this.

As the price for the picopi dropped down to 3€ I can suffer a burned one.

And yes,  a firmware file would be the better option for me ;)

 😊

Have a nice weekend,

Nils