Any interest in a (much) cheaper RomWBW board?

[Wesley Isacks]

By RomWBW board, I mean a RAM+ROM board that brings a RC2014 system up to RomWBW capability - just as the official 512k RAM 512k ROM board does now. Sourcing cheaper 74HCT670s has brought down the price of current designs, but what if we designed them out entirely?

I've gotten the standard 7-chip memory card down to 6 chips, with all support chips being "common" 74HCT parts (each <$0.80 in quantities of one, from mainstream suppliers). So what's the catch? It needs a different RomWBW build to the regular card.

Now, this different build is easy to achieve. I designed the board to be interface compatible with the RetroBrew SBC mapping scheme (32k pages, top page is always top RAM). Building a ROM image is just a matter of creating a config specifying the SBC memory mapper (instead of the Z2 ). The bootloader looks like this:

So this is where the question comes in. Is a cheaper board desired? Do I send a pull request to Wayne to add support for this?

Design, schematic etc for the curious: PickledDog/rc-1024k: 512K+512K RAM/ROM card for RC2014 (github.com)

Even cheaper 128K+128K board PickledDog/rc-256page: 128K+128K fully pageable RAM/ROM card for RC2014 (github.com), this one's 5 chips and has a BOM total of $10

-Wesley

[Alan Cox]

So this is where the question comes in. Is a cheaper board desired? Do I send a pull request to Wayne to add support for this?

Design, schematic etc for the curious: PickledDog/rc-1024k: 512K+512K RAM/ROM card for RC2014 (github.com)

Even cheaper 128K+128K board PickledDog/rc-256page: 128K+128K fully pageable RAM/ROM card for RC2014 (github.com), this one's 5 chips and has a BOM total of $10

-Wesley

The 128K one is particularly nice as it'll work with processors that want low ROM and those that want high ROM. Right now we don't actually have a cheap option for banking 6502/680x/etc - just the 32K/32K ROM/RAM card that Ben did ages ago, or the existing 512K card which boots with ROM bank 0 everywhere.

Alan

[Wayne Warthen]

On Monday, April 19, 2021 at 12:39:56 AM UTC-7 Wesley Isacks wrote:

So this is where the question comes in. Is a cheaper board desired? Do I send a pull request to Wayne to add support for this?

Fine by me if there is sufficient interest.

-Wayne 

[Jeff Greer]

It would be a good option moving forward, mostly for new projects or those that do not have a RomWBW board already.

I would be interested in one even though I already have three cp/m systems.

Thank you,

Jeff

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/f1e68e7d-c2f7-4374-a3ab-20555d4b6fcbn%40googlegroups.com.

[Mark T]

It might be possible to design a similar module that would be compatible with an unmodified RomWBW.

Top 32k is always mapped to fixed 32k ram, even though this is done as two 16k pages. Then bottom 32k is mapped as two 16k pages from either ram or rom.

So capture what is written only to one of the lower 16k pages, ignore the least significant bit and use this to address a 32k page from rom or ram for the bottom 32k of the z80 address space.

This probably needs a tighter address decoder to decode page write, maybe using 74hct688.

I’m not sure which 32k page from 512k ram is used as fixed page for the top 32k of the z80 address space, but maybe a simple change to RomWBW would work with both the existing 512k rom+ram module or the cheaper replacement.

Mark

[Wayne Warthen]

On Monday, April 19, 2021 at 12:41:01 PM UTC-7 Mark T wrote:

I’m not sure which 32k page from 512k ram is used as fixed page for the top 32k of the z80 address space, but maybe a simple change to RomWBW would work with both the existing 512k rom+ram module or the cheaper replacement.

Currently, it is always the top 32K of physical RAM that is mapped to the top (common) 32K of CPU address space.  I didn't quite follow what you are suggesting as an alternative, so can't really comment on that.

-Wayne

 

[Alan Cox]

Let me know once you have a set of ROM images for the 128K and 512K. I've added it to the emulator, so once there is something to test and debug with I'll merge it properly and push it.

Alan

[Alan Cox]

So capture what is written only to one of the lower 16k pages, ignore the least significant bit and use this to address a 32k page from rom or ram for the bottom 32k of the z80 address space.

This probably needs a tighter address decoder to decode page write, maybe using 74hct688.

Not really - the existing ports are mirrored and since you don't care about bit 0 you don't care about decoding A0. ROMWBW would try and write two values, both would go to the same port and bit 0 would be ignored.

Realistically though you would still need a different ROMWBW in places - amongst other things to report a different system ID for these boards because other software most definitely does care.

To me it seems if you are going to do that it would be better to make the bank switch routine called via a RAM vector and properly build a multi-target RC2014 ROMWBW. It's possible today to build a generic CP/M ROM for most setups. The generic ROM I use can boot the SC108, SC114, paged ROM system, and standard 512/512K with a range of serial ports and provides CP/M 3 on all of them, some with ramdisk, so the autodetection logic is all there if anyone wants to use it.

(The experimental one also works on 1802, 6502 and 680x but that's mostly me being silly ;) )

Alan

[Bill Shen]

Over last 10 months, Wayne had ported ROMWBW to 3 of my hardware.  The first port was based on Z80 (ZRC) which has very similar banking scheme, i.e., 2 meg RAM divided into 64 32K banks with common bank at the top of the RAM.  Wayne ported that in matter of days.  The other two designs were Z280-based (ZZ80MB, ZZRCC) and porting were far more challenging.  Nevertheless, Wayne was able to port them in few weeks.  All you need to do is providing Wayne with an accurate description of your hardware (or better yet, a real hardware) and he should be able to come up with a ROMWBW port quickly.

  Bill

[Wayne Warthen]

On Monday, April 19, 2021 at 2:54:50 PM UTC-7 Bill Shen wrote:

Over last 10 months, Wayne had ported ROMWBW to 3 of my hardware.  The first port was based on Z80 (ZRC) which has very similar banking scheme, i.e., 2 meg RAM divided into 64 32K banks with common bank at the top of the RAM.  Wayne ported that in matter of days.  The other two designs were Z280-based (ZZ80MB, ZZRCC) and porting were far more challenging.  Nevertheless, Wayne was able to port them in few weeks.  All you need to do is providing Wayne with an accurate description of your hardware (or better yet, a real hardware) and he should be able to come up with a ROMWBW port quickly.

Thanks for the kind words Bill.  Yes, I am generally happy to port to new hardware as long as it fits the general requirements of RomWBW and the hardware is to be made available broadly.

-Wayne 

[Mark T]

Addressing the top 32k of the 512k as the fixed top 32k of the z80 64k is probably fairly easy, I just couldn’t remember if that was what RomWBW already used.

[Mark T]

I couldn’t remember what order the pages were written or if the page address of the top 32k was rewritten at any time, so thought we might need the address decoding tight enough to ignore writes to the top two memory map registers.

I wasn’t aware of any software running under RomWBW that would write to the map registers. Do you have an example? Or is this for other operating systems in RomWBW?

It seems a reasonable requirement to allow rom at high memory as an option, preferably under software control, so on reset has rom everywhere.

[Alan Cox]

On Tue, 20 Apr 2021 at 00:23, Mark T <mark...@gmail.com> wrote:

I couldn’t remember what order the pages were written or if the page address of the top 32k was rewritten at any time, so thought we might need the address decoding tight enough to ignore writes to the top two memory map registers.

A1 needs to be checked but not A0, and conveniently the existing hardware doesn't seem to check A3. So you need to check A1/A2/A4/A5/A6/A7/IORQ/WR - which would indeed need a 74HCT688. On the other hand I think the 74HCT253 side could be redone with one half of a 74HCT139 (A15 and RAMEN as the inputs MREQ the enable) and RAM/ROM CS as outputs, which

would leave the other side free to feed the 138 and thus provide the extra decode: or you could use a 688 and then use the other side of the 139 as an inverter and wire Q4 through it to \WR on the flash so you normally have it write protected. It's not impossible to hit a code pattern that burns a flash chip by accident but it does happen. Could certainly do with a protect jumper otherwise.

I wasn’t aware of any software running under RomWBW that would write to the map registers. Do you have an example? Or is this for other operating systems in RomWBW?

ROMWBW boots other operating systems that need to be told the board is different. Fuzix for example.

Alan

[Wesley Isacks]

I am pleasantly surprised that this generated so much discussion! I'll try to cover some of the things that were brought up.

ROM images - I have built some new ones against RomWBW 3.1.1-pre.71:

rc-1024k/firmware at main · PickledDog/rc-1024k (github.com)

rc-256page/firmware at main · PickledDog/rc-256page (github.com)

Replacing the '253 with a '139 - I tried this initially, and it seemed I would need a diode-OR to get the desired outcome. Unless I'm overlooking something? The '253 seemed the "smallest" way to do this.

Using the unused Q4 as a write-protect - I like this idea! Although unless decoders/gates can be "freed" from other functions, I'd have to add a chip. FLASH4 and/or RomWBW would need to patched. Unless RomWBW has such an API already?

Replacing the '138 with a '688 - I used a '688 initially, but swapped it for the '138 in the interests of cost reduction (since I don't see much else going on in the 0x70-0x7F space). Regarding checking A1/A2 - I'm not sure where we are going here. Is this to make it (outwardly) resemble the Zeta 2 mapper? I was going for the SBC mapper, but I see that the Z2 mapper could be approximated in this way. Would this be more useful?

-Wesley

[Wayne Warthen]

On Tuesday, April 20, 2021 at 2:21:37 AM UTC-7 Wesley Isacks wrote:

Using the unused Q4 as a write-protect - I like this idea! Although unless decoders/gates can be "freed" from other functions, I'd have to add a chip. FLASH4 and/or RomWBW would need to patched. Unless RomWBW has such an API already?

I assume you are talking about write protecting the ROM, right?  Making the RAM write protected would be very hard to support in software.

RomWBW currently has no concept of dynamically making the FLASH write-only or not.  It could be added.  To be useful, I would think it also be necessary to modify Will Sowerbutts' FLASH utility to enable/disable the write protect.  I'm not sure how useful this would be because FLASH chips are not easy to overwrite inadvertently -- I have never heard of it happening.  Some boards take the approach of a jumper to enable/disable write protect on FLASH -- simple and effective.

[Wesley Isacks]

The ROM, yeah. Protecting the RAM would be a challenge for sure. And indeed, programming the flash is hard (but not impossible) to do accidently, given the specific series of commands you have to send to it. I've never heard of corruption happening either, but maybe Alan has (or he abides the wisdom that anything that can happen, will happen). I was mostly intrigued by the soft-protection idea, and given that RomWBW pleasantly surprises with new (to me) features on a regular basis, I wondered if support for it was already in there.

So yeah, flash protection didn't really cross my mind before then, but I'll add a jumper if I revise the board.

-Wesley

[Wayne Warthen]

On Monday, April 19, 2021 at 2:04:55 PM UTC-7 etched...@gmail.com wrote:

To me it seems if you are going to do that it would be better to make the bank switch routine called via a RAM vector and properly build a multi-target RC2014 ROMWBW. It's possible today to build a generic CP/M ROM for most setups. The generic ROM I use can boot the SC108, SC114, paged ROM system, and standard 512/512K with a range of serial ports and provides CP/M 3 on all of them, some with ramdisk, so the autodetection logic is all there if anyone wants to use it.

Thanks for pointing out your generic ROM work Alan.  I had not seen this before.  There is (of course) some really interesting code in there.  Some of it is not pertinent to RomWBW, but I may indeed plagiarize some pieces of it!  :-)  Auto-detection of the RAM banking mechanism (RBC vs. Zeta) could indeed reduce the number of ROM variations which is definitely a goal.

Thanks,

Wayne 

[Mark T]

I’ve been trying to figure out if Wesley’s schematic could be reduced to three chips instead of four in addition to the rom and ram. All the options still seem to need four chips, but I think it could work with unmodified RomWBW. Using the ‘138 and allowing shadow address X111XX0X.

I think its best to use the ‘153 or ‘253. The ‘139 isn’t going to work as there are more than one condition to enable the ram. ‘156 would work as open collector outputs can be tied together but that also needs pull up resistors, not available in HCT, and the two halves share the same select inputs so it doesn’t provide any extra address decoding.

‘380 could replace ‘174 and ‘32, but its a larger size and a bit rare, so defeats the purpose. 

‘173 is only four bits and needs another chip for the fifth bit so removing the ‘32 doesn’t reduce the chip count. Also the ‘173 would need an inverted reset, though that could be done with the second half of a ‘74

‘395 is another possible, again only four bits, no need to invert the reset, but not a common part and I don’t think available in HCT.

‘268 is six bits, with tristate output, but no reset, so difficult to make sure it gets cleared on power up, similar  problems with ‘373, ‘374, ‘573, ‘574.

Its still been an interesting set of design limits to investigate.

[Bill Shen]

A CPLD like ATF1502AS (Altera EPM7032SLC44 equivalent) is $1.88 from Mouser in quantity of 1.  It can replace all the TTL logic of the 512K RAM/ROM board and have logic left over for a compact flash interface and probably other functions like I2C.  It is probably consider "cheating", however.

[Karl Albert Brokstad]

Bill; its not cheating :)

That would be the ultimate consolidation.

Maybe it is possible since there will be logic left to switch between linear and paged memory mode?

Do you take the challenge? 

Karl

-- 
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/e79d108d-87aa-4397-a6f1-9e18a1e5be0cn%40googlegroups.com.

-----
Karl Albert Brokstad
Kirkeveien 9B, 5072 Bergen
98843314
ka...@brokstad.no

[Mark T]

Not cheating, just a different challenge. Sergei already has a module on Tindie using a cpld and includes the z80, reset and clock, without using smt

I was interested in Wesley’s solution, reducing component cost of the memory mapping with basic ttl, then also modifying that to maintain software compatibility with the unmodified RomWBW. It might just be possible to squeeze it onto a standard module, but very tight when four ttl chips needed.

A cpld version might also benefit from the same reduction in logic, freeing more of the cpld to support other functions, though I think this does break the possibility of booting fuzix.

My preference is for micro SD card rather than compact flash, and/or possibly a serial interface so no additional card needed. 

Bonus points for keeping the standard module outline and not using autorouting:)

[Bill Shen]

Challenge accepted ;-)
I'll start a new post so not to hijack this excellent thread.
  Bill

[Bill Shen]

I do not have Kicad software to display the schematic.  Can someone post a pdf of Wesley Isacks' schematic?
  Bill

[Mark T]

Pdf schematic was in his github.

I think the mods to make it compatible with RomWBW would be:

A1 to ‘138 pin 5 instead of A7.

D1 to ‘174 pin 3 instead of D0

D2 to ‘174 pin 4 instead of D1

D3 to ‘174 pin 6 instead of D2

D4 to ‘174 pin 11 instead of D3

D5 to ‘174 pin 14 instead of D7

Though with cpld you could probably tighten the address decoder to match Output address 01111X00, where the X might be 0 or 1, I can’t remember if RomWBW is using 78 or 7C as the base address for mapping.

[Wayne Warthen]

On Friday, May 14, 2021 at 4:21:24 PM UTC-7 Mark T wrote:

Though with cpld you could probably tighten the address decoder to match Output address 01111X00, where the X might be 0 or 1, I can’t remember if RomWBW is using 78 or 7C as the base address for mapping.

RomWBW uses 0x78, but it is a config setting. 

[Richard Deane]

Don't forget to add the circuitry to allow the cpld to be programmed.

Richard 

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/13830aaa-64b1-442d-bed9-9130206a89ebn%40googlegroups.com.