As I'm away from home (and all the home projects and distractions) I've been scheming on a new Pocket SBC. The plan is to have a large amount of memory and have a hardware paging mechanism to access up to 1MB of RAM and up to 1MB of EEPROM. I'm also leaning towards a paging size of 4KB, which would yield 16 pages against the 65C02 64KB address space.

My current thinking is to implement all of it in a CPLD. The details would include a 4-to-16 decoder to provide the 16- 4KB page selects by using the upper 4 address lines (A12 - A15). The lower 12 address lines (A0 - A11) would directly drive the memory chips. The 16 select lines would drive 16- 8-bit latches, which would provide the extended address lines from A12 - A19. By loading an 8-bit value into the various latches, any of the 16- 4KB pages could be assigned one of the 256 pages within the 1MB of memory.

To allow selecting RAM vs EEPROM, an extra pair of 8-bit latches would be implemented to provide a single bit per 4KB bank to determine if EEPROM is selected (bit = 0) or if RAM is selected (bit = 1). From an I/O standpoint, that would allow up to 2MB of memory to be accessed using 18- I/O addresses.

I'm planning to use Quartus II to start the CPLD project soon. I am wondering however, if there is any value in being able to "read" the memory configuration via the 18 I/O addresses, versus just having whatever OS or control program that's running to manage it. Making the configuration readable would likely require twice as much resources from the CPLD. Any feedback is welcome of course.

_________________
Regards, KM
https://github.com/floobydust

I like the ability to read-back (especially control pins) as it may provide an indication if there is a hardware problem. If a signal line is stuck reading the control pins would show that whereas having the software track the state would not. However, read-back is expensive since it requires more hardware; I would not bother with it unless there were extra resources available.

_________________
http://www.finitron.ca

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

On one of my recent machines I page the ROM in 16KB chunks. In the last byte of each page I put the page number just in case I needed to know the current memory configuration. The only time I used it though was to test if the paging was working.

_________________
Bill

You may want to look at what I did with the 74ls610 that I basically used like you desribed, in my CSA computer http://www.6502.org/users/andre/csa/cpu/index.html

Becaus 74ls610 are scarcce now somewhere on the site I have a replacement circuit

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

So, thanks to everyone for their replies so far...

Rob - Yes, I agree that having the ability to read the configuration back could be useful, but also dependent on the resources of the CPLD. I'm planning to use the EPM240T100, but it will be used for many other functions as a single glue logic.

BDD - of course... the '816 can access up to 16MB, but that isn't a paging setup. One of the things I'm hoping for with the new SBC is the ability to run Fuzix, which requires paging on an 8-bit CPU. Currently, the '816 isn't used in native mode for Fuzix, as they are stating a proper '816 C compiler is required. Maybe at some point that becomes an option... who knows.

BillO - Good idea on placing the page number in the ROM. The current RC2014 512KB ROM/RAM card also pages in 16KB size. Somehow, I think a smaller page size might be more useful, time will tell.

Andre - Yes, I recall reading about the '610 chip and it being scarce. There's also the RC2014 512KB ROM/RAM card which uses a pair of '670 chips. I'll have to search the site for your replacement circuit.

Finally, the plan to use the EPM240T100.... this Altera CPLD has a fair amount of resources, so the hope is that it will provide everything I need/want for a single Glue Chip. This includes:

- Full I/O decoding and signal generation for memory and I/O devices.
- An I/O bus that will handle 8- and 16-bit data devices (SC28L92, DS1501, Microdrive PATA interface).
- Memory Paging as described above.
- CPU Clock at 16MHz and 8Mhz when accessing I/O devices.
- Interrupt processing from the various I/O devices (still need to figure what that is, versus using the CPU only).
- Anything else I forgot about...

_________________
Regards, KM
https://github.com/floobydust

Here's the '610 doc http://www.6502.org/users/andre/hwinfo/ls610/index.html

Note that this already needs in excess of 128 registers (16×8, or if you add more control bits up to 192) if you want to put it into a CPLD.

But it is not a dual ported RAM, just a multiplexed register file, so easy to implement in a CPLD

Edit: Internal diagram: http://www.6502.org/users/andre/hwinfo/ls610/ls610b.png

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Digikey currently claims to have 4167 they want to sell. Or did I look up the wrong chip?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

hmm, the minimum order quanity is 49, which would be ~300 EUR/USD worth of chips. seems a little exessive for a one time project.

also if resources on the CPLD are getting a little tight, would it be an option to do non-uniform paging?
for example the lower 48k of Memory could be split into 12x 4k pages using 8-bit registers, while the upper 16k could just be a single large page that uses a 6-bit register (as the page is 4x larger it doesn't need the bottom 2 bits of the register)
this would only require 102 bits in the CPLD instead of 128 bits.
of course this would likely make working with the pages in software a bit more complicated, but if you only use the upper 16k for some ROM or program RAM, then i think it should be fine.

or you could be really cheeky and use some cheap DP-RAM, with one port being used for the CPU's access and the other for the address decoding. (or use really fast single port SRAM and use the first half of PHI2 to read from it)

After a long 13+ hour day without power (a very large tree limb fell and took out the power lines a block away), I'm finally cooling off and able to get online.... and thanks to all for additional posts today.

Mike B - looks like DigiKey is sourcing from Rochester Electronics. They are showing the same, albeit slightly different pricing and minimum quantity:

https://www.rocelec.com/search?q=74ls610

Proxy - I'm hoping all of the desired functions will fit in the CPLD... I'll find out as I start working on this. Haven't quite started yet.

The 74LS610 will not be a good fit for this project for several reasons:
- A large 40-pin DIP
- A 5-volt only part
- An old part

Granted, I haven't told too much about the new SBC, but it will be a 2-PCB system where they plug together and slide into an extruded alloy case. The PCBs will be about the size of a credit card, so the case will truly be pocket size. It will also be a 3.3-volt system and pretty much all SMT parts so it can actually fit in the case. This basically rules out older parts and larger packages. It will likely be the last W65C02 system I build, hence the desire to make it highly portable and fairly powerful and flexible.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

if it weren't for the chip shortage i would've suggested using a cheap FPGA over a CPLD.
for example the MachoXO2 series comes in the same 100 pin TQFP package like the CPLD you have, at ~8-10 bucks they come with 640 Logic Elements, and at ~11-13 bucks they come with 1280 Logic Elements.

i wonder if we ever get out of this chip drought...

anyways, i assume the point of a pocket sized SBC is to take it with you and use it without any external peripherals or another computer (probably battery powered)
so do you have any plans for on-the-go IO? a UART doesn't really work if you have nothing to connect it to.
for example one of those 8-bit parallel LCDs (320x240 @ 16/24-bit color) designed for Arduinos, they usually have an onboard µSD-card slot and level shifters (or just 245's with 5V tolerant inputs), but i think you can still use them at 3.3V directly. you could use a VIA to easily interface with the display controller and the µSD-card for cheap storage.
the screen is also a touch screen, which is likely not that useful unless you want to implement an onscreen keyboard for writing programs and such. (it would be a lot of work, but it would also mean you wouldn't need an external keyboard)

Yes, the Pocket-SBC is just that... take it with you. It's not battery powered however... either USB or a separate 5V regulated supply. I always have my MacBook Pro with me, so I can attach to that and use the "Serial" app for a console and work away as I care to, including writing code and transferring via Xmodem-CRC to the Pocket-SBC.

Onboard I/O is:

NXP SC28L92 DUART - (one channel is a USB console using an FTDI chip), other channel available on connector and timer used for jiffy-clock.
Maxim DS1501 Realtime Clock - RTC and Alarm function plus NVRAM holds configuration data for selectable profiles.
Hitachi Microdrive with PATA interface - 6GB rotating hard drive... very good performance, adequate storage and low power. Working with a prototype 3.3V system now running DOS/65.

The rest is a couple momentary switches for Reset and Panic (NMI), a power switch and a few indicator LEDs for Power, USB activity and Microdrive activity.

Semiconductor shortage... yea, it's not fun! I've not been able to easily source some chips I'd like to experiment with and my new car ordered in July 2021 is still not completed, waiting for specific modules, which are waiting on chips to get completed. Who knew it could get this bad

_________________
Regards, KM
https://github.com/floobydust

If you can get hold of an EPM570 (570 logic elements instead of 240 on the EPM240) it might help. They claim to be able to supply them here: https://www.utsource.net/itm/p/11244047.html
They're not cheap and I've found utsource have a habit of increasing the price after you've placed an order.

awwww, my dreams of a 65C02 based Phone will have to wait for another day!
honestly i'd like to build something around one of those LCDs myself, but i'm usually really scared of SMT, not because of the soldering (except those SOJ packages), but because i don't have any way to desolder them again, so once i put them on a PCB they're basically gone.
and 65xx chips are not cheap!

also, can i ask why Microdrive instead of Compact Flash? from what i was able to find online (why is information on those things so hard to find?) both use the same interface and connector, so why a spinning disk over solid state storage? or is it just what you have lying around?


oof, at those prices it seems way more feasibly to get a high end STM32 Microcontroller and just emulate the decoding logic with it.