160kB RAM/ROM Module

382 views
Skip to first unread message

Phillip Stevens

unread,
Feb 12, 2021, 6:03:27 AMFeb 12
to RC2014-Z80
As mentioned, on other threads I just finished a very simple RAM/ROM Module.

I guess the main feature is that it is really simple / cheap. Just 4 chips.
There are no jumpers or selectors. Super simple. Super cheap.

You get 32kB ROM at 0x0000, which can be paged out at address 0x38.
There are 2 banks of 64kB RAM, switchable at 0x30.
Basically, the design is cribbed from the SC114, but without any frills.

This functionality covers most of the standard ROMs, and this is the only use case I have. Pictures attached. Once proven I'll update this thread.

RC2014_MEMORY_MODULE_BRD.png

RC2014_MEMORY_MODULE_SCH.png
Cheers, Phillip


karlab

unread,
Feb 12, 2021, 6:48:17 AMFeb 12
to RC2014-Z80

Hi Phil.

The traces on the PCB are beautiful.
Do you do the tracing manually?

Karl

Phillip Stevens

unread,
Feb 12, 2021, 7:01:50 AMFeb 12
to RC2014-Z80
karlab wrote:
The traces on the PCB are beautiful.
Do you do the tracing manually?

Thanks Karl.
Yes I do them manually. It is sort of a karma inducing "join the dots" game for me.
Usually I'll start a few times, moving the components around, before finding the right flow for the board.
And, I'm always trying for the 0-via outcome.
Cheers, Phillip

Mark T

unread,
Feb 12, 2021, 2:09:08 PMFeb 12
to RC2014-Z80
Hi phillip,

Just curious if you tried rearranging the address lines to the ‘259, does it simplify the routing or just screw it up on the outputs? Sometimes it simplifies the routing with decoders or multiplexers, sometimes it messes it up more on the outputs.

Mark

Wesley Isacks

unread,
Feb 12, 2021, 6:45:25 PMFeb 12
to RC2014-Z80
I concur, the trace routing is lovely! I feel the same way about manual routing - it's almost meditative. I'm sure my tune would change if I had to do it every day, though.
-Wesley

Phillip Stevens

unread,
Feb 12, 2021, 9:52:37 PMFeb 12
to RC2014-Z80
Mark T wrote:
Just curious if you tried rearranging the address lines to the ‘259, does it simplify the routing or just screw it up on the outputs? Sometimes it simplifies the routing with decoders or multiplexers, sometimes it messes it up more on the outputs.

Hi Mark,

It turns out that keeping the addressing on the '259 wasn't hard to route, so I didn't think to change it. But, if it would have meant using a via I probably would have changed it, because karma.

If you know the AS5C1008, you'd note that the address lines have been optimised for layout karma though.

When thinking about this Module, I was looking to try to get the simplest and cheapest solution for supporting CP/M and the standard MS Basic builds. I think Steve has nailed it with the SC114 design. I spent a few hours looking for alternatives, like a 64kB RAM device (doesn't exist, afaik) or better 74' logic options, but couldn't find any.

Then, given that the '4075 has so many free latches, I started piling on some tri-colour LEDS, and some output pins. But then I slept on it and realised that it was not the original design goal, so I ripped all that out and went back to the bare minimum.

I still think it would be nice, and possible, to make the RAM into 32kB pages. But if I'm not mistaken that would add a bit more logic to the A15 addressing. So I discarded that idea too. Perhaps it is worth coming back to at some stage.

Cheers, Phillip

Wesley Isacks

unread,
Feb 12, 2021, 11:30:24 PMFeb 12
to RC2014-Z80
I'm working on 32K RAM pages next! Will post when I have something working.
-Wesley

Phillip Stevens

unread,
Feb 13, 2021, 2:44:14 AMFeb 13
to RC2014-Z80
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

As we have no RAM in a common area, the only way that I can think that this would work would be to have a code fragment stored by the bootloader in both of the RAM 64kB pages.
This would allow RAM to be copied back and forward across the whole address range, except the section where the code fragment exists of course.

I've mocked up some relocatable code and it is only 0x18 Bytes, so it would (for example) fit between the INT 0x38 and the NMI 0x66 addresses. Or, it could be copied into the shadow RAM CP/M FCB, and then loaded into the working RAM CP/M FCB just before it was needed. Lot's of options of where to put it.

I would have liked to make 64kB copies an option, but the overhead is too much in my opinion. It is better to divide up a copy into 256 Byte chunks in C, and do it that way. That preserves performance for small structure copies, and for floating point or other smaller copies.

The only caveat is that the same code has to be in both RAM banks in the same location, otherwise the PC will get borked and writing code to resolve that is beyond me.

Anyway, this is the guts of what I can put into z88dk so that all the shadow ram can be used from C.

12    0000              ; HL is the source address
13    0000              ; DE is the destination address
14    0000              ; B is the number of bytes to copy
15    0000              
16    0000              ; Assemble with z88dk for RC2014 BASIC
17    0000              ; zcc +rc2014 -subtype=basic -v -m --list ramcopy.asm -o ramcopy -create-app
18    0000              
19    0000              defc RAM_TOGGLE    = $0030  ; The RAM bank is toggled by outputing 1/0 to 0x0030
20    0000              
21    0000              PHASE 0x0040
22    0040              
23    0040              .shadowcopy                 ;
24    0040  37              scf                     ; set our banks in reverse (more general if ccf used)
25    0041  17              rla                     ; carry to bit 0
26    0042  D3 30           out (RAM_TOGGLE),a      ; now in other bank
27    0044  1F              rra                     ; recover carry
28    0045              
29    0045              .ramcopy
30    0045  7E              ld a,(hl)               ; get the byte
31    0046  23              inc hl
32    0047              
33    0047  3F              ccf                     ; toggle bank
34    0048  17              rla                     ; carry to bit 0
35    0049  D3 30           out (RAM_TOGGLE),a      ; now in other bank
36    004B  1F              rra                     ; recover carry and byte
37    004C              
38    004C  12              ld (de),a               ; store the byte
39    004D  13              inc de
40    004E              
41    004E  3F              ccf                     ; toggle bank
42    004F  17              rla                     ; carry to bit 0
43    0050  D3 30           out (RAM_TOGGLE),a      ; now in other bank
44    0052  1F              rra                     ; recover carry and byte
45    0053              
46    0053  10 F0           djnz ramcopy            ; decrement B
47    0055              
48    0055  AF              xor a                   ; get to front bank
49    0056  D3 30           out (RAM_TOGGLE),a      ; now in front bank
50    0058  C9              ret
51    0059              
52    0059              DEPHASE
53    0019              

Any thoughts on how to do this better / another way?

Cheers, Phillip


Phillip Stevens

unread,
Feb 13, 2021, 2:56:28 AMFeb 13
to RC2014-Z80
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

I would have liked to make 64kB copies an option, but the overhead is too much in my opinion. It is better to divide up a copy into 256 Byte chunks in C, and do it that way. That preserves performance for small structure copies, and for floating point or other smaller copies.

This does up to 64kB copies. Not too much overhead either... 

12    0000              ; HL is the source address
13    0000              ; DE is the destination address
14    0000              ; BC is the number of bytes to copy
15    0000              
16    0000              ; Assemble with z88dk for RC2014 BASIC
17    0000              ; zcc +rc2014 -subtype=basic -v -m --list ramcopy.asm -o ramcopy -create-app
18    0000              
19    0000              defc RAM_TOGGLE    = $0030  ; The RAM bank is toggled by outputing 1/0 to 0x0030
20    0000              
21    0000              PHASE 0x0040
22    0040              
23    0040              .shadowcopy                 ;
24    0040  37              scf                     ; set our banks in reverse
25    0041  17              rla                     ; carry to bit 0
26    0042  D3 30           out (RAM_TOGGLE),a      ; now in other bank
27    0044  1F              rra                     ; recover carry
28    0045              
29    0045              .ramcopy
30    0045  78              ld a,b                  ; swap BC to use cheap djnz
31    0046  41              ld b,c
32    0047  4F              ld c,a
33    0048  03              inc bc                  ; make sure MSB in C is non-zero (without affecting carry)
34    0049              
35    0049              .copyloop
36    0049  7E              ld a,(hl)               ; get the byte
37    004A  23              inc hl
38    004B              
39    004B  3F              ccf                     ; toggle bank
40    004C  17              rla                     ; carry to bit 0
41    004D  D3 30           out (RAM_TOGGLE),a      ; now in other bank
42    004F  1F              rra                     ; recover carry and byte
43    0050              
44    0050  12              ld (de),a               ; store the byte
45    0051  13              inc de
46    0052              
47    0052  3F              ccf                     ; toggle bank
48    0053  17              rla                     ; carry to bit 0
49    0054  D3 30           out (RAM_TOGGLE),a      ; now in other bank
50    0056  1F              rra                     ; recover carry
51    0057              
52    0057  10 F0           djnz copyloop           ; decrement LSB
53    0059              
54    0059  0D              dec c                   ; decrement MSB
55    005A  20 ED           jr NZ,copyloop
56    005C              
57    005C  AF              xor a                   ; get to front bank
58    005D  D3 30           out (RAM_TOGGLE),a      ; now in front bank
59    005F  C9              ret
60    0060              
61    0060              DEPHASE

Steve Cousins

unread,
Feb 13, 2021, 4:58:08 AMFeb 13
to RC2014-Z80
Hi Phillip

As others have said, your board is a true work of art. I'm really impressed with the zero via implementation. I never seem to get close to that.

I use the same memory control circuit on several of my designs. I was unable to find a cheaper and/or lower chip count solution. To support this scheme I included an API in SCM v1.1 to allow a single byte to be written to or read from the second RAM page. This is limited to the top half of memory but enables bootstrap code to be copied over. 

Steve

Alan Cox

unread,
Feb 13, 2021, 8:34:19 AMFeb 13
to rc201...@googlegroups.com
On Sat, 13 Feb 2021 at 07:44, Phillip Stevens <phillip...@gmail.com> wrote:
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

As we have no RAM in a common area, the only way that I can think that this would work would be to have a code fragment stored by the bootloader in both of the RAM 64kB pages.
This would allow RAM to be copied back and forward across the whole address range, except the section where the code fragment exists of course.

Fuzix on these boards uses a small piece of code in the ROM to bootstrap copying common helper code into both banks, which then works pretty much as you describe. It's a shade more complicated because it self modifies for speed and has to self modify the right bits in the right bank. There is a method in SCM for bank to bank copy, but because of the way things work out I can't actually use it directly and Fuzix ends up scanning the ROM to find it and call it directly - which works out fine.

My CP/M port for the fixed Simple80 (the original board has a bug) also supports using the second bank as a RAMdisc for CP/M in a similar way, as does my generic CP/M ROM. It's possibly not useful because the CF adapter is faster than bank switching copy 8)

Alan

Phillip Stevens

unread,
Feb 13, 2021, 8:55:37 AMFeb 13
to RC2014-Z80
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

As we have no RAM in a common area, the only way that I can think that this would work would be to have a code fragment stored by the bootloader in both of the RAM 64kB pages.
This would allow RAM to be copied back and forward across the whole address range, except the section where the code fragment exists of course.

Fuzix on these boards uses a small piece of code in the ROM to bootstrap copying common helper code into both banks, which then works pretty much as you describe. It's a shade more complicated because it self modifies for speed and has to self modify the right bits in the right bank. There is a method in SCM for bank to bank copy, but because of the way things work out I can't actually use it directly and Fuzix ends up scanning the ROM to find it and call it directly - which works out fine.

My CP/M port for the fixed Simple80 (the original board has a bug) also supports using the second bank as a RAMdisc for CP/M in a similar way.

Alan,

What mechanism did you use to hold the bank status?
Did you publish your Simple80 code?

I think using the carry bit to carry bank status works well as it isn’t affected by loop counting, and is relatively fast to recover without using a register. It will support 8080 too.

But there is probably a better way that I’ve overlooked entirely. Very open to suggestions.

P.

Bill Shen

unread,
Feb 13, 2021, 10:44:53 AMFeb 13
to RC2014-Z80
In Simple80, R16 needs to be pulled down rather than pulled up as in the original schematic.
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:simple80

Alan and I have talked about copying data into all Z80 registers, including the alternate registers then switch bank and move data from registers to new bank.  Because there are several Simple80 boards out there, I did not correct the design mistake but wrote a non-banked version of CP/M3 instead.
  Bill

Alan Cox

unread,
Feb 13, 2021, 1:09:13 PMFeb 13
to rc201...@googlegroups.com

What mechanism did you use to hold the bank status?

Not sure I understand the question
- In general I know the bank because I have a bank "variable" I patch to be different in each bank copy, so a simple load of the address tells you
- In a copier you don't need to know because the two halves of the code being executed as it bounces bank to bank can be different anyway (and you can have to/from copiers). For a ramdisc
you also probably want a 128byte fixed size copier (especially for 8080 and 8085)

Did you publish your Simple80 code?

 
The non optimised one I used is, but the optimized one I forgot never got merged because I support SC108 and SC114 on the same kernel and never got around to a nice copier for both models. Those are in the Fuzix repository on github, and the universal CP/M ROM is in RC2014ROM repository (both github.com/EtchedPixels)

I will need to dig for the optimized one but basically it patches the out statements saving the re-use of the bc/de registers and uses de not ix. A truely optimized version (especially for 8080) would need to use the stack pointer.


Phillip Stevens

unread,
Feb 13, 2021, 9:12:04 PMFeb 13
to RC2014-Z80
Phillip wrote:
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

As we have no RAM in a common area, the only way that I can think that this would work would be to have a code fragment stored by the bootloader in both of the RAM 64kB pages.
This would allow RAM to be copied back and forward across the whole address range, except the section where the code fragment exists of course.

Alan wrote:
Fuzix on these boards uses a small piece of code in the ROM to bootstrap copying common helper code into both banks, which then works pretty much as you describe. It's a shade more complicated because it self modifies for speed and has to self modify the right bits in the right bank.

Thanks Alan, Bill,

Good to hear I'm on the right track, and a code fragment in both banks at the same PC is necessary. I've found the code in Fuzix file sc108.s.
 
There is a method in SCM for bank to bank copy, but because of the way things work out I can't actually use it directly and Fuzix ends up scanning the ROM to find it and call it directly - which works out fine.

In the SCC v1.1 code I only find information which indicates that the shadow RAM is not implemented.
In SCC v1.23 I find following.

; **********************************************************************
; Read from banked RAM
;   On entry: DE = Address in secondary bank
;   On exit:  A = Byte read from RAM
;             F BC DE HL not specified
;             IX IY I AF' BC' DE' HL' preserved
H_RdRAM:    LD   C,kBankPrt     ;Bank select port address
            LD   B,1            ;Make B=1
            OUT  (C),B          ;Select secondary RAM bank
            LD   A,(DE)         ;Read from RAM
            DEC  B              ;Make B=0
            OUT  (C),B          ;Select primary RAM bank
            RET


; **********************************************************************
; Write to banked RAM
;   On entry: A = Byte to be written to RAM
;             DE = Address in secondary bank
;   On exit:  AF BC DE HL not specified
;             IX IY I AF' BC' DE' HL' preserved
H_WrRAM:    LD   C,kBankPrt     ;Bank select port address
            LD   B,1            ;Make B=1
            OUT  (C),B          ;Select secondary RAM bank
            LD   (DE),A         ;Write to RAM
            DEC  B              ;Make B=0
            OUT  (C),B          ;Select primary RAM bank
            RET

And the ROM to RAM API looks like this.

; **********************************************************************
; Copy from banked ROM to RAM
;   On entry: A = ROM bank number (0 to n)
;             HL = Source start address (in ROM)
;             DE = Destination start address (in RAM)
;             BC = Number of bytes to copy
;   On exit:  AF BC DE HL not specified
;             IX IY I AF' BC' DE' HL' preserved
H_CopyROM:  LDIR                ;Only one bank so just copy memory
            RET

So, I'd like take the H_CopyROM API as a given, since it is also used by LDIR. with a small clarification around A register.

and make a H_CopyRAM API suggestion.

;   On entry: Interrupts disabled unless you know better
;             A  = Source RAM bank (0 / 1)
;             HL = Source start address (in ROM)
;             DE = Destination start address (in RAM)
;             BC = Number of bytes to copy
;   On exit:  AF BC DE HL not specified
;             IX IY I AF' BC' DE' HL' preserved

Depending on the space available, it might be best to do the BC shuffle and MSB increment in the calling functions. Though to keep things consistent I hope to do it in the copied code fragment. I'll see what comes out, and where the fragment can fit nicely.

Also, interrupts need to be stored and disabled, which can be best done in the calling C functions. Assembly programmers can look after it for themselves.

3     0000              SECTION code_user
4     0000              
5     0000              PUBLIC shadowcopy
6     0000
10    0000              ;   On entry: Interrupts disabled unless you know better
11    0000              ;             A  = Source RAM bank (0 / 1)
12    0000              ;             HL = Source start address (in ROM)
13    0000              ;             DE = Destination start address (in RAM)
14    0000              ;             BC = Number of bytes to copy
15    0000              ;   On exit:  AF BC DE HL not specified
16    0000              ;             IX IY I AF' BC' DE' HL' preserved
17    0000             
21    0000              defc RAM_TOGGLE    = $0030  ; The RAM bank is toggled by outputting 1/0 to 0x0030
22    0000
23    0000              PHASE 0x0050
24    0050
25    0050              .shadowcopy
26    0050  D3 30           out (RAM_TOGGLE),a      ; now in other bank
27    0052  1F              rra                     ; move current bank to carry
28    0053
29    0053  78              ld a,b                  ; swap BC to use cheap djnz
30    0054  41              ld b,c
31    0055  4F              ld c,a
32    0056  0C              inc c                   ; make sure MSB in C is non-zero (without affecting carry)
33    0057
34    0057              .copyloop
35    0057  7E              ld a,(hl)               ; get the byte
36    0058  23              inc hl
37    0059              
38    0059  3F              ccf                     ; toggle bank
39    005A  17              rla                     ; carry to bit 0
40    005B  D3 30           out (RAM_TOGGLE),a      ; now in other bank
41    005D  1F              rra                     ; recover carry and byte
42    005E
43    005E  12              ld (de),a               ; store the byte
44    005F  13              inc de
45    0060
46    0060  3F              ccf                     ; toggle bank
47    0061  17              rla                     ; carry to bit 0
48    0062  D3 30           out (RAM_TOGGLE),a      ; now in other bank
49    0064  1F              rra                     ; recover carry
50    0065
51    0065  10 F0           djnz copyloop           ; decrement LSB (without affecting carry)
52    0067
53    0067  0D              dec c                   ; decrement MSB (without affecting carry)
54    0068  20 ED           jr NZ,copyloop
55    006A
56    006A  AF              xor a                   ; get to front bank
57    006B  D3 30           out (RAM_TOGGLE),a      ; now in front bank
58    006D  C9              ret
59    006E
60    006E              DEPHASE

If the fragment exists in ROM only, then the top 32kB of shadow ram can be used.
If the fragment is copied on initialisation into both RAM banks (say somewhere in Page 0) then the whole 64kB of shadow RAM can be used.

Getting fancy would be to treat the shadow RAM as an additional C heap, and write malloc() and free() functions for it... but that's for another day.
P.

Alan Cox

unread,
Feb 13, 2021, 10:17:22 PMFeb 13
to rc201...@googlegroups.com

Also, interrupts need to be stored and disabled, which can be best done in the calling C functions. Assembly programmers can look after it for themselves.


I made my interrupt handlers save/restore the bank but that's probably overkill for a CP/M setup

Alan

Phillip Stevens

unread,
Feb 15, 2021, 3:27:15 AMFeb 15
to RC2014-Z80
Phillip wrote:
I've been thinking about a method to use the additional 64kB of shadow RAM which will be available in Wesley and my new Modules, and also for those that have one of Steve's SC114 boards. Those solution that have a shadow RAM toggle at 0x30 (though it could be any register as needed).

Spencer,

I think there's an issue with us using the 0x30 (or 48 in decimal) port to toggle the 64kB RAM pages because your Paged ROM Module also does something else with that port.
What did you design to happen when out (48),0 or out (48),1 are issued?

I might need to add a configuration to ensure that the data section asm_shadowcopy load preparation from ROM is only done if so configured.
Cheers, Phillip

Spencer Owen

unread,
Feb 15, 2021, 1:49:33 PMFeb 15
to rc201...@googlegroups.com
On Mon, 15 Feb 2021 at 08:27, Phillip Stevens <phillip...@gmail.com> wrote:

I think there's an issue with us using the 0x30 (or 48 in decimal) port to toggle the 64kB RAM pages because your Paged ROM Module also does something else with that port.
What did you design to happen when out (48),0 or out (48),1 are issued?

I might need to add a configuration to ensure that the data section asm_shadowcopy load preparation from ROM is only done if so configured.
Cheers, Phillip

Hi Phillip, 

This was quite a few years ago, so my memory is a bit hazy, but the thinking behind that would be that additional 32k RAM pages plus a 32k ROM page could be used, where the additional RAM pages are selectable by sending additional OUT (56),0 commands. Sending an OUT (48),0 would reset the '393, and bringing you back to the ROM page - either for speed (to save cycling though all the other pages) or to come back to a known page in case you lose track.

With careful software use, 3 additional 32k pages can be connected directly to the '393, just making sure that the counter is only incremented to 0, 1, 2, 4 or 8. However, with something like a 4-to-16 decoder inbetween the '393 and the RAM, 16 pages can be accessed.

This is fairly academic, though, as I don't think anybody has used this (previously undiscussed) feature.  Certainly the software side is beyond my abilities, and with RomWBW happily working with 512k ROM and 512k RAM, I'm not sure there is really much call for it.

Spencer 

Phillip Stevens

unread,
Feb 15, 2021, 10:52:46 PMFeb 15
to RC2014-Z80
Phillip wrote:
I think there's an issue with us using the 0x30 (or 48 in decimal) port to toggle the 64kB RAM pages because your Paged ROM Module also does something else with that port.
What did you design to happen when out (48),0 or out (48),1 are issued?
 
Spencer Owen wrote: 
Sending an OUT (48),0 would reset the '393, and bringing you back to the ROM page - either for speed (to save cycling though all the other pages) or to come back to a known page in case you lose track.
This is fairly academic, though, as I don't think anybody has used this (previously undiscussed) feature.

Thanks for clarifying / confirming Spencer.

I had written half a page notes here, but then browser crash and, poof, gone.

Suffice to say that it is a pity that I didn't read your schematic or even my own code before proceeding, but it doesn't really matter in the end.
The user will just have to be aware of which memory type they are have when using the functions, or they will be bounced back to ROM.

For z88dk, it doesn't make a difference, since for both ROM builds (ACIA and SIO) the asm_shadowcopy relocatable code can be initialised into both (or twice into one) banks without any care.

The asm_shadowcopy code is assigned to the DATA section, so it will be automatically decompressed and located in RAM, along with the user's shadowwrite() and shadowread() functions.
In the builds I've been playing with, it happens to be the first thing in DATA, so is located at 0x8000. But that isn't guaranteed.
Then, using the functions so placed from ROM, it is possible to relocate them to any other RAM location as needed, with a bit of further juggling.

So I believe that's a memcpy()similar set of functions done, and ready for use with a SC108, SC114 or Wesley's rc-ramrom.

P.

Phillip Stevens

unread,
Mar 11, 2021, 7:50:05 PMMar 11
to RC2014-Z80
Phillip Stevens wrote:
As mentioned, on other threads I just finished a very simple RAM/ROM Module.

I guess the main feature is that it is really simple / cheap. Just 4 chips.
There are no jumpers or selectors. Super simple.

You get 32kB ROM at 0x0000, which can be paged out at address 0x38.
There are 2 banks of 64kB RAM, switchable at 0x30.
Basically, the design is cribbed from the SC114, but without any frills.

This functionality covers most of the standard ROMs, and this is the only use case I have.
Pictures attached. Once proven I'll update this thread.

RC2014_MEMORY_MODULE_BRD.png

And, here's the update. I've build some up some of these PCBs and they work as intended.

IMG_1355.jpg

The only issue was that the PCB manufacturer misunderstood my dimension instructions, and sent me rectangular PCBs.

I mean, what were they thinking?

One small advantage over separate ROM and RAM boards when using the standard Backplane 8, is that you don't need a separate flying /PAGE wire.
That's very convenient.

I've put my excess PCBs up on Tindie as the "Memory Module". I've five rectangular PCBs that need to be filed to shape. Use "REWORK" code to get them at $3.00.

As always, postage from AU is a PITA, so let me know if you'd like to make your own and I'll send the Gerber files.

Cheers, Phillip

Wesley Isacks

unread,
Mar 12, 2021, 6:35:22 PMMar 12
to RC2014-Z80
Looking good! And I see you went for a 4-layer board, very nice.
I should list my extra boards on Tindie... I have quite a collection of them at this point. How hard is it to set up a store?
-Wesley

Phillip Stevens

unread,
Mar 12, 2021, 7:12:49 PMMar 12
to RC2014-Z80
Wesley Isacks wrote:
Looking good! And I see you went for a 4-layer board, very nice.

Thanks.

I should list my extra boards on Tindie... I have quite a collection of them at this point. How hard is it to set up a store?
 
It is very easy to set up a store. Really you just have to describe what your product is.
The only background thing to do is to work out what your shipping rates are.

From AU it is pretty easy really to work out shipping rates. If you cross the water (i.e. outside AU), I can never get out of the Post Office for less than ~A$30.
Which is a real issue when you're selling a $3.00 item.
 
I've put my excess PCBs up on Tindie as the "Memory Module". I've five rectangular PCBs that need to be filed to shape. Use "REWORK" code to get them at $3.00.
As always, postage from AU is a PITA, so let me know if you'd like to make your own and I'll send the Gerber files.

P. 

Phillip Stevens

unread,
Mar 26, 2021, 12:48:12 AMMar 26
to RC2014-Z80
As mentioned, on other threads I just finished a very simple RAM/ROM Module.

I guess the main feature is that it is really simple / cheap. Just 4 chips.
There are no jumpers or selectors. Super simple.

You get 32kB ROM at 0x0000, which can be paged out at address 0x38.
There are 2 banks of 64kB RAM, switchable at 0x30.
Basically, the design is cribbed from the SC114, but without any frills.

This functionality covers most of the standard ROMs, and this is the only use case I have. 
IMG_1355.jpg

The only issue was that the PCB manufacturer misunderstood my dimension instructions, and sent me rectangular PCBs.

One small advantage over separate ROM and RAM boards when using the standard Backplane 8, is that you don't need a separate flying /PAGE wire.
That's very convenient.
 
The replacement RC2014 shaped PCBs have finally arrived, and they're listed on Tindie now.

I've put my PCBs up on Tindie as the "Memory Module".
While I've got some of the rectangular (electrically identical) PCBs left over, I'll throw them in one for one, with any orders.

As always, postage from AU is a PITA, so let me know if you'd like to make your own PCBs and I'll send you Gerber files.

Cheers, Phillip
Reply all
Reply to author
Forward
0 new messages