Improved RAM/ROM 512k module

[Bill Shen]

I'm thinking of a better, faster and cheaper RAM/ROM 512k module.  The improved RAM/ROM 512K is fully backward compatible with the original, but with added features:

- ROM emulation, with few jumper configurations, the ROM socket can be populated with RAM and data uploaded into the RAM via serial port at 115200 baud,
- EPROM programmer, programming software can be loaded in RAM to program the EPROM,
- A serial port, the same serial port used to load ROM image can be reuse as a regular serial port.
- A real-time clock like PCF8563 that can generate 32Hz output driving the interrupt,
- Battery backup for RAM & RTC,
- SPI port,
- Faster, should be able to run 20MHz
- Cheaper, the board should be around $50.

  Bill

[Nils-Arne Dahlberg]

Sounds interesting.

/N-A

[Alan Cox]

On Tuesday, 6 August 2019 12:58:46 UTC+1, Bill Shen wrote:

> - ROM emulation, with few jumper configurations, the ROM socket can be populated with RAM and data uploaded into the RAM via serial port at 115200 baud,

> - EPROM programmer, programming software can be loaded in RAM to program the EPROM,

EPROM or flash ?

> - A serial port, the same serial port used to load ROM image can be reuse as a regular serial port.

Is the plan that these two go together - so you download a programmer and the data into a RAM, and then flash the ROM (or some of it as it won't all fit in one go), then boot from the ROM ?

> - A real-time clock like PCF8563 that can generate 32Hz output driving the interrupt,

> - Battery backup for RAM & RTC,

Nice - that lets you do some really interesting tricks including checking for a magic value and register dump and just popping all the registers and doing a ret on power up if so, which in turn means you can tweak the CP/M BIOS to have a hotkey that suspends the machine mid whatever you are doing, and then restore on resume (it's a shade more complex as you have to re-init the CF, UART etc but not a lot)

> - SPI port,

> - Faster, should be able to run 20MHz
> - Cheaper, the board should be around $50.

Sounds good to me. Would this all be through hole though ?

Alan

[Mark T]

Hi Bill
FT245 is a lot faster for download than uart, if you are using cpld it would easily fit the logic to impersonate the 6850.

Something like ADM694 for battery backup would also provide a power fail indicator, using the reset output to gate the memory decoder so two or more rams can have power fail write protect. It might even be possible to configure the system to resume after power fail. Watchdog can also be used as a system reset, leave Watchdog input floating and ground it for a second or two to trigger reset.

Mark

[Bill Shen]

Alan,
When I said 'ROM' I really meant 'Flash'.  A better title for my post would be "Improved RAM/Flash 512K module".

I'm not quite clear myself on the operating concept, either.  If the board is populated with Flash & RAM, then flash programming software is loaded into RAM and programmed into Flash.  If the board is populated with 2 RAM, then software is loaded directly into RAM and run from RAM.  The concept may change as the design progresses.  I'm incline to send off the PC board design first and work on CPLD in parallel.

I'm thinking of a hybrid approach: SMT for the CPLD (Altera EPM7128SQC100) that will be soldered down and programmed by me.  The rest of the boards are through-hole components.  This gives the capability/flexibility of larger CPLD without users having to program CPLD and also lower cost of the component.  I can solder & program the Altera SMT part very quickly, so hybrid approach is no hassle for me.  $50 for the hybrid kit seems very do-able.  Can't ship lithium battery internationally, however.

Mark,
It takes 60 seconds or so to load 512K of RAM, but realistically ROM emulation is mostly for software development which is likely lesser than 32K, so it takes lesser than 5 seconds to load at 115200.  The serial port can be implemented in CPLD so it also save cost over FT245.  ADM694 is a good choice for battery backup although I have hundreds of DS1210--one of those "cheaper by the dozens and dozens" deal...

  Bill
PS, schematic attached.  It is close enough I'll just go ahead and layout the board and see what happens.

[Greg Holdren]

Nice, This will also double as CPLD playground which is nice also by no loading the memory.

Maybe the spare I/Os can be put on some kind of header with ground and power to make it easier to interface with other circuitry.

Greg

[Mark T]

For option to use Ram for U2 you might want to consider routing pin 29 via the cpld, as this is WE on ram.

If you add links to select supply for U2 from either BAT or Vcc then you could have option of two battery backed rams. Connect both CEs to the DS1210 and use OE and WE for address selection. U2 decoupling would of course be after the link, direct to U2 vcc pin.

Cost of the FT245 is offset by the FTDI adapter, but i guess almost everyone already has ftdi adapters.

Mark

[Mark T]

I should clarify the comment on pin 29. I meant a separate output pin from the cpld, not common with bank0 to U3.

[Sergey Kiselev]

Hi Bill,

A few remarks:

1. It is possible to program the Flash ROM on the current 512 KB ROM / 512 KB RAM module in system. The FLASH utility written by Will Sowerbutts is included in RomWBW (https://github.com/willsowerbutts/flash4).

2. I would not recommend using DS1210 for new designs. It has been discontinued by manufacturer and pretty much becoming an unobtanium. MAX693/ADM693 (MAX691, ADM693, MAX695, ADM695, and also LTC691/LCT965) is a better alternative, and it is being manufactured by at least 2 companies (Linear Technology had been merged with Analog Devices, I think).

3. The pinout of a 512 KB SRAM slightly different from a pinout of 512 KB Flash ROM. You'll need to use jumpers or some logic in the CPLD to switch the functions of a couple of pins.

4. (Good) serial ports are difficult to implement. Not sure if CPLD would have enough logic to do that. It might be easier to add a UART IC or to use a microcontroller with a serial port to load SRAM if that is the intention.

-SK

[Richard Deane]

Please can you verify that it is directly Romwbw compatible during your prototype testing
Richard

[Bill Shen]

Thank y'all for the inputs.  I compensated for the RAM/Flash differences as suggested by Mark T and Sergey.  I'm concerned about the geopolitical situation in Hong Kong so I hurried up and sent off several board designs including the Improved RAM/Flash 512K board.  Hopefully I'll have the boards back early next week.
  Bill

[Bill Shen]

Richard,
I don't actually have the original RAM/ROM 512K module and never have used ROMWBW before.  Could you suggest a hardware configuration for verifying the ROMWBW compatibility.  My simple-minded configuration is a Z80 with SIO running at 7.37MHz; should I consider other configurations?
  Bill

[Richard Deane]

That should be fine (z80 sio and 7.3 MHz) but also add in CF card for disk store, with option to also test IDE interface. If aiming for 100% rc2014 compatibility then you should be able to burn/program a rom with the rc2104 flavour prebuilt release, or build your own, actually quite simple as all tools and build scripts are included for use under Windows.

Richard

[Alan Cox]

On Thursday, 8 August 2019 12:44:34 UTC+1, Bill Shen wrote:

Richard,
I don't actually have the original RAM/ROM 512K module and never have used ROMWBW before.  Could you suggest a hardware configuration for verifying the ROMWBW compatibility.  My simple-minded configuration is a Z80 with SIO running at 7.37MHz; should I consider other configurations?

Fuzix should just boot if ROMWBW does. The only funnies in the  512K RAM/ROM I know of are the partial decodes. When you have it running I can send you a CF image to check it gets to the boot prompt.

Alan

[Karl Albert Brokstad]

Hi Bill

I have a bunch of the 512k RAM/ROM laying around. If you are interested I'll send you one ASAP.

Karl

[Bill Shen]

My pc boards are done and on their way to Hong Kong just as the situation there is deteriorating.  I'm monitoring the shipment closely.  Of course the pc boards are trivial matters comparing to the unrest and the likely disasters hanging over Hong Kong.  I hope all can be resolved peacefully, but I'm an incurable optimist.
  Bill

[Bill Shen]

Hong Kong's passenger terminals were shut down, but its cargo hub was not affected by the protesters, at least 24 hours ago.  My pc boards passed through Hong Kong without delay so I received the boards this afternoon right on schedule.

Build up one board, this is what the Improved RAM/Flash 512K board looks like.  The first order of business is program the CPLD with the functionalities of the original RAM/ROM 512K.  After the basic functionalities are checked out, the improved features can be added in the CPLD.
  Bill

[Richard Lewis]

Hi Bill, 

Always amazed by how quickly you design and build these boards! Would you be willing to share your Quartus project with me? 

-Richard

[Greg Holdren]

Looks good!

Hahaha I was comparing your mounted CPLD to my unsoldered one and it the same part but off by 6 weeks earlier. Was hopping it was a 5V part.

Greg 

On Tuesday, August 13, 2019 at 4:54:47 PM UTC-7, Bill Shen wrote:

[Bill Shen]

Richard,
I'll be happy to share the CPLD.  I generally create a page in retrobrewcomputers.org where I publish the schematic, gerber plots, CPLD, and software.  This board will be published the same way.

The wonderful thing about CPLD is I can design a circuit board without fully define the functionalities of a board.  I like to send 3 or 4 PCB designs at a time to save shipping, so I often send off PCB designs and work on the CPLD designs while the boards are being made.  The boards are so cheap, the turn around time so short, and I'm comfortable with cutting and patching pc boards that there are very little reason to get the board 100% correct the first time.

  Bill

PS, you may not like my CPLD designs--I tend to do them in the schematic format to have better control of the CPLD resources.  For an example, this is the banking logic that replaces the decoding and bank mapping logic of the original RAM/ROM 512K board.

[Richard Lewis]

Thanks Bill! Yes, I keep forgetting that your stuff is on retrobrew. Stuck in my head is: source code = Github. 

I'm hooked on CPLD/FPGA as well. I'm finding it a lot easier to prototype in VHDL and ModelSim as opposed to getting lost in a maze of wires on a breadboard. I managed to get a basic Z80 system up and running on a breadboard and booting SCM but then my head exploded tracing back through the rat's nest of wires to debug. 

Since I have a software engineering background it's easier for me to visualize a circuit in VHDL. Fortunately Quartus can convert schematic BRD files into VHDL or Verilog. The resulting VHDL is a bit messy but can be cleaned up easily enough. 

-Richard

[Mark T]

Hi Bill,
I was going to follow a similar process with CPLD, design the cpld logic while waiting for the pcbs, but then i was a bit concerned about the design fitting in an EPM7128S after assigning pins as i was already at 98% usage while letting quartus select the pins. As I’d already roughed out the design in vhdl, this one isn’t so easy to draw schematic, i assigned the pins according to my pcb schematic and layout. Lucky I did as it would no longer fit, error that Lab G needed 39 macrocells but only has 36. This wasn’t the main design for the pcb but a secondary use based on an extra connector that i added into a little extra space, still it would be annoying to find it didn’t fit after submitting the board to be manufactured. Problem was due to a wide multiplexer to the data bus and six of the data lines were in Lab G. After moving two of the data lines I ended up with a whole bunch of strange error messages, essentially due to still not fitting. After moving another signal into Lab G, and moving another data line out of Lab G i was able to successfully fit the design to the pcb pinout. Hopefully any changes to the vhdl don’t push it back over the limit.

Mark

[Bill Shen]

While waiting for a batch of pc boards to show up, I thought I'll revisit the improved RAM/ROM512K and incorporate my recent experience with synthesized ROM in CPLD.  The goal is having an EPROM programming capability and the ability to emulate ROM with RAM.  These are two separate features, but supported with the same hardware with different jumper options.

The setup consists of the RAM/ROM 512K board a Z80 CPU (Karlab's 23c, Z80 CPU and clock) on RC2014 backplane.  As an EPROM programmer, it starts out with an empty EPROM, so there is a small bit of ROM code in CPLD that loads a serial bootloader into RAM, which, in turn, load the EPROM programmer in RAM space  The banked memory is set up so RAM is at upper 32K and EPROM at lower 32K.  EPROM programmer will first erase the EPROM and notify operator it is ready to accept the EPROM image.  As the image is serially uploaded, the EPROM programmer writes it into the blank EPROM.  It has 86uS at 115200 baud to program each byte of data.   To verify, the EPROM programmer notify the operator to send the image again, and verify the incoming data with EPROM.

As a ROM emulator, the 512K EPROM is replaced with a 512K emulation RAM and changed a couple jumpers.  The same ROM code in CPLD loads a slightly different serial bootloader that, in turn, loads the EPROM image into the emulation RAM and then jump into 0x0.

Something interesting to work on while waiting for DHL to show up.

  Bill

[Bill Shen]

Here is the SST39F040 programmer as implemented in RR512K:
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:rr512k#eprom_programmer

The hardware setup is a RC2014 backplane with a Z80 board with clock(Karlab 23c) and the RR512K board populated with SST39F040.  The bootstrap code synthesized in CPLD is quite small, 16 bytes.  It reads 256 bytes from CPLD's serial port and stores the serial data in memory and then jump to it.  The 256-byte serial loader loads the SST39F040 programmer and jump to it.  The SST39F040 programmer first asks user to confirm erasure of the EPROM, erases it, and asks user to upload the EPROM image file in Intel Hex format.  The programmer writes the data into EPROM as it receives it, so when the file transfer is completed, the EPROM is also programmed.  It takes about 2 minutes to transfer & program 512K data at 115200-N81.  I verified the content of the programmed EPROM on TL866II programmer.  It verified OK.

Once I have the programming framework for SST39F040, programmer for AT49F040 should be fairly easy to do.

  Bill

Edit:  DHL will deliver my new pc boards tomorrow afternoon.  Now I have a Z80 with 512K RAM/ROM and native programming capability, I'll work on porting ROMWBW to it in the meantime.

[Karl Albert Brokstad]

Very Nice

Most people only need a simple programmer.

Karl

On Thursday, 23 April 2020 14:38:37 UTC+2, Bill Shen wrote:

Here is the SST39F040 programmer as implemented in RR512K:
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:rr512k#eprom_programmer

The hardware setup is a RC2014 backplane with a Z80 board with clock(Karlab 23c) and the RR512K board populated with SST39F040.  The bootstrap code synthesized in CPLD is quite small, 16 bytes.  It reads 256 bytes from CPLD's serial port and stores the serial data in memory and then jump to it.  The 256-byte serial loader loads the SST39F040 programmer and jump to it.  The SST39F040 programmer first asks user to confirm erasure of the EPROM, erases it, and asks user to upload the EPROM image file in Intel Hex format.  The programmer writes the data into EPROM as it receives it, so when the file transfer is completed, the EPROM is also programmed.  It takes about 2 minutes to transfer & program 512K data at 115200-N81.  I verified the content of the programmed EPROM on TL866II programmer.  It verified OK.

Once I have the programming framework for SST39F040, programmer for AT49F040 should be fairly easy to do.

  Bill

[Bill Shen]

The alert readers may wonder why I need to port ROMWBW to RR512K since RR512K should already be compatible with the original RAM/ROM512K.  Yes, RR512K is compatible with the original RAM/ROM512K, but there is a serial port in RR512K which may possibly replace the original 6850 board.  So the "porting" exercise is to design the serial port in the CPLD such that it can be recognized by ROMWBW as an ACIA port.  I was successful in getting the CPLD serial port recognized as the ACIA.  So the hardware is consisted of a Z80 with clock (Karlab 23c) and a RR512 with ROMWBW installed.

RetroBrew HBIOS v2.9.1, 2019-06-03

RC2014 Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1
512KB ROM, 512KB RAM

ACIA0: IO=0xA0 ACIA MODE=115200,8,N,1
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
IDE: IO=0x10 DEVICES=1
IDE0: NO MEDIA

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         --
Char 0      ACIA0:      RS-232            115200,8,N,1


RC2014 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC
Disk: (0)MD1 (1)MD0 (2)IDE0

Boot Selection? C

Loading CP/M 80 v2.2...



CBIOS v2.9.1 [WBW]

Configuring Drives...

   A:=MD1:0
   B:=MD0:0
   C:=IDE0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6
   J:=IDE0:7

   1935 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

B>dir
B: ASM      COM : CLRDIR   COM : COPY     CFG : COPY     COM
B: DDT      COM : DDTZ     COM : DIF      COM : DUMP     COM
B: ED       COM : FA16     CFG : FDISK80  COM : FILEATTR COM
B: FILEDATE CFG : FILEDATE COM : FLASH    COM : INITDIR  CFG
B: INITDIR  COM : LDDS     COM : LDP2D    COM : LINK     COM
B: LOAD     COM : MBASIC   COM : NULU     COM : PIP      COM
B: PUTDS    COM : RELOG    COM : RMAC     COM : STAT     COM
B: SUBMIT   COM : SUPERSUB COM : TD       CFG : TD       COM
B: UNARC    COM : XSUB     COM : ZAP      COM : ZCAL     COM
B: ZCNFG    COM : ZCNFG24  CFG : ZDE      COM : ZPATH    COM
B: ZSCONFIG COM : ZXD      CFG : ZXD      COM : ASSIGN   COM
B: FDU      COM : FORMAT   COM : MODE     COM : OSLDR    COM
B: RTC      COM : SURVEY   COM : SYSCOPY  COM : SYSGEN   COM
B: TALK     COM : TIMER    COM : XM       COM : INTTEST  COM
B: CPM      SYS : ZSYS     SYS
B>

[Bill Shen]

Since RR512K was designed for higher speed bus, I tried it out with a 22MHz Z80 and try the RCZ80_std.rom of ROMWBW 3 while I'm at it.  It boots and gets into CP/M just fine and it is definitely faster.  XMODEM is not working, however.  I think I need to look into my handshake implementation.

I'm happy to see ROMWBW supports KIO.  I'll need to use KIO to run the system at 22MHz.  Another possibility is replacing the Z80 board with Z84C1516 which has KIO built in.

  Bill

RomWBW HBIOS v3.0.1, 2020-04-04

RC2014 Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1
512KB ROM, 512KB

RAM

ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 NOT PRESENT
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------

Char 0      ACIA0:      RS-232            115200,8,N,1
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         --

Disk 3      IDE1:       Hard Disk         --


RC2014 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1

Boot Selection? C

Loading CP/M 80 v2.2...

CBIOS v3.0.1 [WBW]

Formatting RAMDISK...

Configuring Drives...

   A:=MD1:0
   B:=MD0:0

   4140 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

B>

dir
B: ASM      COM : CLRDIR   COM : COMPARE  COM : COPY     CFG
B: COPY     COM : DDT      COM : DDTZ     COM : DUMP     COM
B: ED       COM : FA16     CFG : FDISK80  COM : FILEATTR COM
B: FILEDATE CFG : FILEDATE COM : FLASH    COM : INITDIR  CFG
B: INITDIR  COM : LDDS     COM : LDP2D    COM : LINK     COM
B: LOAD     COM : MBASIC   COM : NULU     COM : PIP      COM
B: PUTDS    COM : RELOG    COM : RMAC     COM : STAT     COM
B: SUBMIT   COM : SUPERSUB COM : TD       CFG : TD       COM
B: UNARC    COM : XSUB     COM : ZAP      COM : ZCAL     COM
B: ZCNFG    COM : ZCNFG24  CFG : ZDE      COM : ZPATH    COM
B: ZSCONFIG COM : ZXD      CFG : ZXD      COM : ASSIGN   COM
B: FDU      COM : FORMAT   COM : MODE     COM : RTC      COM
B: SURVEY   COM : SYSCOPY  COM : SYSGEN   COM : TALK     COM
B: TIMER    COM : XM       COM : INTTEST  COM : CPM      SYS
B: ZSYS     SYS
B>

[Wayne Warthen]

On Thursday, April 23, 2020 at 10:23:35 PM UTC-7, Bill Shen wrote:

The alert readers may wonder why I need to port ROMWBW to RR512K since RR512K should already be compatible with the original RAM/ROM512K.  Yes, RR512K is compatible with the original RAM/ROM512K, but there is a serial port in RR512K which may possibly replace the original 6850 board.  So the "porting" exercise is to design the serial port in the CPLD such that it can be recognized by ROMWBW as an ACIA port.  I was successful in getting the CPLD serial port recognized as the ACIA.  So the hardware is consisted of a Z80 with clock (Karlab 23c) and a RR512 with ROMWBW installed.

Hi Bill,

Very nice work.

I'm curious if you made any changes to RomWBW to get the detection working?

Also, note that there was a deficiency in the RomWBW ACIA detection code that has been fixed in the latest updates at the dev branch of GitHub.  Let me know if you run into detection issues with the latest RomWBW and I can probably help you.

-Wayne

[Bill Shen]

Wayne,
I didn't change the RCZ80_std.rom at all. I 'cheated' by looking at your detection code and modified the hardware to fit. The detection algorithm seems reasonable but the part that threw me was adding 0x20 to the base address which eat up big chunk of scarce I/O space. I can redundantly decode a specific address in CPLD easily, but that's extra burden for people design with TTL logic.
Bill

[Wayne Warthen]

It turns out that once I fixed the code, I did not need to use the base address offset anymore.  The latest detection code uses the "real" base address.  However, it does depend on  the value of the TDRE, DCD, and CTS bits when read from the command port.  When the chip's reset bit is set, the bits should all read 0.  When the chip's reset bit is cleared, the TDRE bits should be 1 and the other two should be 0.

-Wayne

[Bill Shen]

Wayne,
If you've fixed the code so you are not doing detection through base+offset, then that's great. I was referencing and testing fairly old RomWBW sources. The RESET-check-data-all-0-clearReset-check-TDRE is a good test. I have designed the hardware specifically to pass the test.
Bill

[Mark T]

Hi Bill,
Is the 22mHz limited by the serial interface or the memory interface?

Mark

[Bill Shen]

Mark,
I don't know where the limit is. 22MHz Z80 has been producible for many different designs, so I just pick it as a starting point. I probably will try up to 29.5Mhz CPU clock. The serial port is always at 115200.
Bill

[Fredrik Axtelius]

Oh, yes, yes, yes, absolutely fantastic. I constantly find myself in situations where I need a ROM emulator.

I have had a few over the years but they where all expansive and kinda sucked.

Will you use RAM to emulate ROM or flash (which I assume is what everyone means when you write eprom?)?

Please add some control over a few general i/o's so one can toggle reset for example, or control BUSREQ, HALT.

And maybe an input or two.

And if the emualtions is from RAM, please allow the protocol to modify bytes anywhere in the RAM, if possible.

--Fredrik

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/75a900e9-b120-4cf3-b0ac-db0ffc7647dc%40googlegroups.com.

[Bill Shen]

Hi Fredrik,
I hope you are not reading too much into the ROM emulation function.  It is designed to replace the EPROM device with a RAM and has a mechanism to load the Intel Hex file into RAM through an auxiliary serial port.  So instead of use the Intel Hex file to burn a EPROM, the hex file can be loaded into RAM through the auxiliary serial port.  Since it is in RAM, the memory can be changed.  This is the basic function of what I called a ROM emulator.

More advanced features like having hardware watchpoints generating interrupts or halt or instrumentation output is certainly do-able with the existing CPLD, but capturing instructions before and after the watchpoints require more hardware than it currently has.
  Bill

On Saturday, April 25, 2020 at 10:58:24 AM UTC-6, Fredrik Axtelius wrote:

Oh, yes, yes, yes, absolutely fantastic. I constantly find myself in situations where I need a ROM emulator.

I have had a few over the years but they where all expansive and kinda sucked.

Will you use RAM to emulate ROM or flash (which I assume is what everyone means when you write eprom?)?

Please add some control over a few general i/o's so one can toggle reset for example, or control BUSREQ, HALT.

And maybe an input or two.

And if the emualtions is from RAM, please allow the protocol to modify bytes anywhere in the RAM, if possible.

--Fredrik

On Fri, Apr 24, 2020 at 10:00 PM Bill Shen <coinst...@gmail.com> wrote:

Mark,
I don't know where the limit is.  22MHz Z80 has been producible for many different designs, so I just pick it as a starting point.  I probably will try up to 29.5Mhz CPU clock. The serial port is always at 115200.
  Bill

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to retro...@googlegroups.com.

[Fredrik Axtelius]

> I hope you are not reading too much into the ROM emulation function.

Yes I was :(

Well, I had plans to design one myself, guess it's time.

--Fredrik

To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/a8aa57b6-6b29-4543-becf-87bcd40ea34e%40googlegroups.com.

[Mark T]

Maybe take a look at Tom Storey’s schematic posted in recent thread “They use to be called cross-assemblers.”.

As I mentioned in that thread it might be interesting to use busreq instead of wait for stepping cycles if the address and data was latched, as that would also leave the bus available for memory access.

Mark

[Bill Shen]

Thinking about improving the Improved 512K RAM/ROM board :)

The idea is to get rid of the 512K RAM and EPROM and replace it with 2meg x8 DRAM and a compact flash drive.  DRAM is cheap and DRAM controller is easy to do in CPLD.  The CF drive serves as the storage of EPROM content; at power up, a bootstrap program copies data from predefined area in CF disk to DRAM so now it looks like a 512K RAM/ROM board.  CF also serves as a normal CF drive.  Don't need EPROM programming feature anymore because CF disk can be programmed with a workstation.

Wonder what we can do with another meg of memory?

  Bill

[Karl Albert Brokstad]

You may use the extra memory as ram disk, or as video memory.

Karl

 

[Richard Deane]

An MSX implementation running CP/M3 :)

[Richard Lewis]

Will Sowerbutts did something like that for his socZ80 used the 8MB SDRAM on his FPGA board and wrote a memory manager for it. He had to add a block RAM cache in front due to latency issues. 

[Alan Cox]

On Saturday, 9 May 2020 22:16:23 UTC+1, Richard Lewis wrote:

Will Sowerbutts did something like that for his socZ80 used the 8MB SDRAM on his FPGA board and wrote a memory manager for it. He had to add a block RAM cache in front due to latency issues.

To be fair it needs the cache because its running at 128MHz.  It's wickedly fast running Fuzix (in fact Fuzix actually started life from Will's port of UZI to socZ80).

I've got various 8bit machines with silly amounts of memory. The SocZ80 has 8MB, the ZX Evolution (a crazy over the top Russian ZX spectrum) with 4MB and although alas not working an Apple IIgs. Only the 11gs can really make use of the memory because it has an actual decent video resolution and GUI. I've yet to work out what to do with all the memory in the SocZ80 or the Evolution. 1MB yes, 2MB maybe, 4 umm hard, 8.. silly, 16MB maybe on a 68000.

Some of it is just down to program size and CPU performance. An 8MHz Z80 can realistically only use 64K per program, so apart from specially coded banked stuff (which would mostly be graphics) you'd need to be running 16 things at once to use 1MB. That's 500KHZ per thing actively running at once. Stuff not currently running can live on CF card at very low cost.

Without graphics a PDP 11/73 could happily handle 10 developers in 4MB and about 1MIP throughput so I guess an 18MHz Z180 ought to be able to field the same. I just can't imagine a 10 user system without memory protection would end well! (yes the -11 has smarter I/O controllers, but the disks are much slower and you could do a smart I/O controller on RC2014 - in fact I've just finished soldering up a dual port RAM and ATMega board. Now I need to learn how all this newfangled AVR stuff works (I could have gone 8051 but programming the 8051 is about as much fun as punching yourself in the face).

Alan

[Alan Cox]

On Saturday, 9 May 2020 14:14:16 UTC+1, Karl Albert Brokstad wrote:

You may use the extra memory as ram disk, or as video memory.

Karl

Last time I measured it the CF card was faster than the RAMdisc on my CP/M3 boxes. RAMdisc requires you mess around with bank registers, CF doesn't and CF runs at RAM speed for an 8bit micro.

Alan

[Colin MacArthur]

Hello Bill,

GREAT board...

The dual RAM with serial load & battery backup would allow for EASY testing of new "ROM CODE" as it could be loaded into the RAM @ 0000h and then executed...

The  EEPROM Programmer option makes it VERY useful for people that don't have a EEPROM Burner...

I was wondering if it may be possible to rework the board to use a EMP7128SLC84 PLCC &  8-DIP RTC (DS1337?), this would make it easy for those of us that can't solder the 100 pin SMD.

I understand that it would be closer to 102mm x 102mm board BUT so USEFUL....

Thank-You

CM

[Bill Shen]

Colin,
Thought about your proposal a bit.  It is entirely possible to put the CPLD design in 84 PLCC EPM7128S.  I also went back and read this thread again and realized I've already done the EPROM programming function and porting of ROMWBW.  Gosh, I've done some good works--if I can only remember them...

Yes, I think I can redesign the board, get rid of the battery-back logic, and replace the QFP100 with PLCC84.  It should fit in the standard RC2014 format of 50mm x 102mm.  With the addition of the RC2014 Z80 board, it can serve as EPROM programmer.  It can also run ROMWBW once the appropriate EPROM is programmed.  It should run fine at 2x Turbo of 14.7MHz, possibly 3x Turbo.

It may have room to add a CF interface, but I think I'm getting greedy...

It looks like I have several designs to go out to JLCPCB while waiting for 4 board designs to come back.
  Bill

[Bill Shen]

Colin,
I believe I've mentioned ZZ80MB about a year ago.  It was designed to be put together with all through hole components and without the need of any programmer, no EPROM programmer, no CPLD programmer.  It is now revision 2, I can boot up in serial bootstrap mode and run CP/M, but I still have not done the EPROM programmer function nor porting ROMWBW to it.  When you mention EPROM programmer, I think of ZZ80MB.

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:zz80mb:zz80mbr2

[Bill Shen]

Colin,
This is what a revised RAM/ROM512K with EPM7128SLC84 looks like.  Battery back logic and RTC are removed, so the design simplifies significantly.  It is 2-layer 50mm X 102mm pc board. 
  Bill

[Colin MacArthur]

Looks GREAT...

Thank-You

As you know, I like to use NVRAM (DS1250 / M48Z512 / DS1213D / ETC ) as a quick way to test BOOT ROM changes.

This board will work GREAT for z80 & z180 paged applications...

I will add it to my Sept jlcpcb order...

Thank-You again

CM

[Bill Shen]

This is rev1 of 512K RAM ROM using builder-friendly CPLD in 84-pin PLCC.  I added a socket for CPU oscillator, so all it needs to run ROMWBW is a Z80 CPU board.  The Z80 clock is nominally 14.7MHz, but it runs successfully with 22MHz clock as well.

The board has additional functionalities as determined by the 3 jumpers next to the RC2014 bus.  It can operate with a blank EPROM by jumper select the serial port bootstrap function and load the program and data into RAM and turn around to program a new EPROM. 

The board also has lots of spare CPLD I/O pins which can have user-defined functions.

  Bill

On Tuesday, August 6, 2019 at 5:58:46 AM UTC-6 Bill Shen wrote:

I'm thinking of a better, faster and cheaper RAM/ROM 512k module.  The improved RAM/ROM 512K is fully backward compatible with the original, but with added features:

- ROM emulation, with few jumper configurations, the ROM socket can be populated with RAM and data uploaded into the RAM via serial port at 115200 baud,
- EPROM programmer, programming software can be loaded in RAM to program the EPROM,
- A serial port, the same serial port used to load ROM image can be reuse as a regular serial port.
- A real-time clock like PCF8563 that can generate 32Hz output driving the interrupt,
- Battery backup for RAM & RTC,
- SPI port,
- Faster, should be able to run 20MHz
- Cheaper, the board should be around $50.

  Bill

[Bill Shen]

I created a new homepage for rev1 of RR512K here: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:rr512k:rr512k_rev1

The board has been tested with ROMWBW rev 1.9.1 at 14.7MHz.  The EPROM programmer function has been checked out with updated serial bootstrap loader and SST39F040 programmer.

The CPLD has sufficient spare capacity and I/O pins to do I2C, SPI, and WS2812B interface.  I will update the homepage when I have these new features working.

  Bill

[Bill Shen]

Add a 4-pin I2C connector at the top edge of the board; modified the CPLD equation with a bit-bang register at I/O location 0x9E controlling the I2C signals SDA and SCL.  This is the same logic as my other SBC with I2C interface so it is compatible with previous software.  However, I'm trying out a new software; it displays a binary black & white picture generated using the photo conversion program image2cpp, https://javl.github.io/image2cpp/   Image2cpp can convert any photo to binary black & white 128x64 image and output it in format that can be displayed on 128x64 OLED display.  The binary image is quite small, 1024 bytes.  In case you don't recognize the image, it is the iconic pictures of laughing Marilyn Monroe.

What would be really cool is have a program that converts video to collection of 128x64 binary images then store them in memory and playback as animated pictures.  That kind of software is way beyond me, however.
  Bill

[Bill Shen]

Remembered that I had Z80, 68008, 6502, and 6809 CPU cards for G8PP.  Tried out the Z80 CPU card on RR512K.  It works...kinda; it really needs a power jack for 5V input and a reset button.  Other than that, it is running ROMWBW at 22MHz.

The other CPU cards all have the same 40-pin RC2014 female header that has the same address and data signals assignments as RC2014, but the control signals varies slightly due to difference in CPU.  The idea is to reprogram CPLD signal assignments depending on the CPU type so RR512K can work with different CPU cards.
  Bill

[Colin MacArthur]

Off the wall question...

As the 39SF040 allows Byte-Programing, with the correct driver, would you be able to write a file to the RomWBW ROMDISK?

or

A modified "SAVE" command to allow programs in Intel hex format to be loaded @0100h and saved to the ROMDISK? 

CM

[Wayne Warthen]

On Friday, November 6, 2020 at 11:00:21 AM UTC-8 Colin MacArthur wrote:

Off the wall question...

As the 39SF040 allows Byte-Programing, with the correct driver, would you be able to write a file to the RomWBW ROMDISK?

or

A modified "SAVE" command to allow programs in Intel hex format to be loaded @0100h and saved to the ROMDISK? 

Although the 39SF040 can program a byte at a time, I think it still requires erasing in 4K blocks.  Phillip Summers is already working on a new ROM driver module ("flashfs.asm") that is intended to allow writes to a 39SF040.  Although the 39SF040 has a 4K block size, he is going to block/deblock in the driver.  You can check that work out in the dev branch in the flashfs.asm file.

-Wayne 

[Bill Shen]

Colin,
What Wayne said, SST39F040 is a sector (4K) erase, byte program device.  It is easy enough to erase one or more sectors and save an image into designated location, but to add a file in ROMdisk and add the corresponding entries in CP/M directories is significantly more difficult.
  Bill

[Bill Shen]

Recently I was toying with the idea of producing selected Z80 SBC running at 29.5MHz.  I've built enough Z80 running at 22MHz and 25.175MHz that I know vast majority of 20MHz Z80 can run up to 25.175MHz, which is useful because that is the VGA scan frequency.  I've found some Z80 would fail at 29.5MHz, but over half of them still work.  By 'work' I mean:
*  Run memory diagnostic while sweeping supply voltage from 4.75V to 5.25V
*  Boot into CP/M and do full disk copy with verify from disk B to disk A
*  Transfer megabyte-size file using XMODEM
*  Pass the comprehensive instruction test, zexall.com

This morning I did the similar tests on an Improved RR512K board plus a Z80 board (Karlab #12C) and successfully ran ROMWBW (v2.9.1) at 29.5MHz.  A few data points: XMODEM file transfer rate at 115200 is 5.2K/S, hardware handshake is still needed at 115200, current consumption is 200mA, Z80 is not even warm; zexall takes 26.5 minutes to complete.
  Bill

[Colin MacArthur]

GREAT NEWS...

I will have to dig through my recycled Full / Half can supply and see if I have a 29.4912 MHz one.

My jlcpcb shipment arrived so it is time to start "burning my fingers" and get a few RR512K assembled...

THX

CM

[Bill Shen]

Colin,
Tell me the frequency of oscillators you do have that can be integer divided down to within 1% of 1.8432MHz.  I can generate the CPLD file for it.  My experience is 33MHz is about the fastest clock for Z80, maybe 1 out of five Z80 can run to 33MHz.  Your odd is much better at 29.5MHz--about 3 out of 4 should work.

I also uploaded an engineering change to rev1 of RR512K to enable CTS handshake and to install a I2C connector suitable to drive 128x64 OLED display.

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:rr512k:rr512k_rev1:ec_i2c

  Bill

[Colin MacArthur]

Thank-You, looks GREAT.

I will get it working with the 14.75MHz.

After that I will get back to you for a new CPLD file...

THX

CM