"MIB4" card

[MrPix]

Hi folks,

I have been active for a while, and recently started developing some new hardware for the Adam. Yeah, I know, there's a lot of dusty old threads on here with not much to show for it. The difference is I have a quite good track record of making results available for the long haul. I'm sitting on $30k of 5V TTL components here, and I love the machines I played on and used in my past. So, now it's the Adam's turn. I've done some development work, but I thought it would be nice to discuss things here while I wait for China to re-open.

I've been working on combining many of the usually separate cards into a single multi-card aimed at slot 2. 

My current target spec in an "MIB4" card is...

2MB SRAM

+ header to add 2/4/8MB more
- I also have vast VAST quantities of DRAM that is 4Mx4, but I am not confident the Adam could refresh 4K refresh DRAM
- (but using 4Mbytes in two DRAM ICs would make a 12MB card not just cheap, but easy and small)

+ Serial, based around the 28L92 DUART - 2681 register similar - extended baud rates

+ 5V RS-232 level shifters using ADM208E. Both ports implemented.
One port also placed through inverter and level shifted to 3.3v and connected to ESP32 on-board.

+ All ESP32 GPIO available
EPROM slot

+ switches for 4/8/16/32K ROMs
IDE/CF/SD adapter capability
?? parallel port ??

I plan to squeeze all of this onto a slot #2 card using SMD and a high degree of integration. It'll certainly be a 4-layer board. All my boards are open hardware, and I release the schematics and JEDECs/equations typically three to six months after initial release. 

Separately I will be re-implementing the open source ADE Pro SD project on a single board, as microcontroller boards are basically my bliss. Video is my special area of interest and I do plan to do something there too. I have obtained the open source RGB adaptor designed by Citrus3000psi, and plan to re-implement it in a way that makes more sense to me (their design is very good, I just would have reversed it). However, I am looking to implement either a console character device for CP/M, or a 2MB bitmap graphics VGA adapter that I would trop in the top 2MB of the paged memory map (which is why my expansions are planned to top out at 10MB)...

So, those are my plans. They're not promises, and currently half the list is vaporware. That said, discussion and feedback is welcomed. Comments and, in particular, direct technical advice feed directly into my work, because it's hard to pick up a platform you've just used for playing games after 25 or more years and just "know the hardware" and the implications for the OS - and as we all know, the Adam uses a salty blend of 2.5 OS

Sooooooo, let's dance!

[LoTonah]

I'm looking forward to seeing the progress on this one.  As for feedback, maybe if I had read this 2 hours before bedtime, not 2 hours after...

[jblenkle]

I'm not a real fan of Slot 2 unless this has a parallel port...because Slot 2 is where ADAM's parallel printer cards plug in.

[MrPix]

Yes, there’s a parallel port.

[MrPix]

Instead of making this multi-card spread across multiple internal cards, I have decided to make it a single external board.

This does of course mean more room so I might just add ADE to it for good measure! 

[MrPix]

So I've hit a small snag with the Adam memory paging system, which in practice limits us to 1MB. The catch is that the Adam uses IO port 42h, but it only uses the bottom nybble (I spell it nybble, you can spell it nibble, let's co-exist!) which means 16x 32K pages lower 32K and 16x32K pages upper 32K. The upper nybble is ignored. 

Unfortunately, I cannot be sure that in all cases existing software will read/modify/write and not disrupt that upper nybble, so I cannot use it.

What I CAN do is use a pair of other IO bytes to provide extended addressing. The lower of these bytes could be aliased to 42h. For example, if I chose 52h and 53h (which are available) and aliased 52h to 42h in my address decoder then I could do trickery like a write to 42h would also update the bottom nybble of 52h but not disrupt the top nybble by masking the top nybble. 

The consequence of this is that existing software, unaware of the the new scheme, would still operate correctly. New software or updated software, aware of the new scheme, would instead access 50h, with the top nybble also available. They would ALSO have access to 51h and two more nybble pairs.

Thus:
42h: nnnn LLHH
52h: LLHH LLHH
53h: LLHH LLHH

This is quite forward looking, because existing software has access to 1MB, and future software has access to 4GB of 32K upper and lower pages. If 53h is ignored, the pageable range from 52h alone is 16MB.

I looked through the available IO space and selected 52h and 53h because in binary:

42h: 01000010
52h: 01010010
53h: 01010011

So this makes address decoding very compact and quick. 0000000010X001X is really easy to test for!

So I am coming to the community to look at this and raise any unanticipated adverse events or conflicts that might arise. I propose this as a long term fix to a short term decision 38 years ago, that gives a programmer or use a choice to compatibly have a 1MB, 16MB or 4GB system, addressable in a backwards compatible and future-tolerant way.

Discuss.

[NIAD]

As you already know as can be garnered from your explanation, it will be very important to maintain compatibility with existing software that uses/requires expansion RAM. Seeing as there really isn't a need for more than 1Mb of expansion RAM with existing software, your solution for accessing expansion RAM above that seems like the right way to go.

 

Seeing as William H. is really the only one that is pushing the envelop re ADAM software development, his input would seem to be the most important.

 

[MrPix]

2 hours ago, MrPix said:

This is quite forward looking, because existing software has access to 1MB, and future software has access to 4GB of 32K upper and lower pages. If 53h is ignored, the pageable range from 52h alone is 16MB.

A small errata, now it's too late to edit my post.

With 42h, 1MB is addressable. 
With 42h/52h, accessed by 52h, 256MB is addressable.
With 52h/53h, 4GB is addressable.

[ChildOfCv]

8 hours ago, MrPix said:

So I've hit a small snag with the Adam memory paging system, which in practice limits us to 1MB. The catch is that the Adam uses IO port 42h, but it only uses the bottom nybble (I spell it nybble, you can spell it nibble, let's co-exist!) which means 16x 32K pages lower 32K and 16x32K pages upper 32K. The upper nybble is ignored. 

Okay, I refreshed my memory, then reread my post from the other thread, re-checked the emulator source code, and now I see where wires got crossed.

 

First, all 8 bits of port 42 are significant and select a page, so 16MB is automatically on the table.  The confusion comes from discussion of port 60.  The lower niyble of port 60 selects which memory is mapped to the upper and the lower half of 64K.  The lowest 2 bits specify the lower half of memory and the next 2 bits specify the upper half.  The rest of the 4 bits of a write to port 60 are ignored.  But I say again, the entire 8 bits of a write to port 42 are used to page memory.

[MrPix]

*adjusts slightly* That's still only 16MB. My understanding was correct, but I was thinking in nybbles but drew bits - I guess I tripped my mind up by working out binary to find out the easiest sister address to decode in binary.

The impact is still that there are 16 pages of 32K low and 16 pages of 32K high (because odd pages can only be low pages and even only high, which reduces the valid combinations /16.)

This doesn't change the ability to support larger memory maps in a compatible way. It just means that 42h doesn't need to be shadowed. I'll consider the point further and revise the proposal.

[ChildOfCv]

5 hours ago, MrPix said:

The impact is still that there are 16 pages of 32K low and 16 pages of 32K high

No, 256 of each.  The page register is a full byte.

[MrPix]

This is frustrating. The documentation out there said both ways. You have credibility, though. Rando documents on the internet - not so much. I haven't found an official Coleco document that describes the mechanism.

I understand that the whole byte at 42h selects a 64K page to be addressed, subject to the configuration of the bottom nybble at 60h? Thus only 64K blocks can be paged, subject to the Adam's "master decoder" configured by 60h?

If that's correct, extending this system will be much easier than I thought.

Question: is it possible to disable the Z80A's interrupt/auto refresh function, if only SRAM or self-refresh DRAM were fitted?

[MrPix]

Made some progress: 

I've split the RAM off from the MIB card as it takes up too much space and restricts flexibility. It's now a separate daughtercard. Very clean and neat. Just waiting on prototype PCBs.

[jblenkle]

4 hours ago, MrPix said:

Made some progress: 

I've split the RAM off from the MIB card as it takes up too much space and restricts flexibility. It's now a separate daughtercard. Very clean and neat. Just waiting on prototype PCBs.

So refresh my memory...a daughtercard plugs into the main card? I remember the term but haven't heard it in a long time.

[MrPix]

I’ve designed a standard header that is really compact and will go on my multi-card. It will take expansions, and they can stack. So in future I don’t need to redesign the whole card. Just a new daughter card to upgrade the main card. I hope to include two of these headers so future options are easy to add. It also means people don’t need to buy things they don’t want, so if they already have memory they can skip my memory card and save a few bucks. 

[ChildOfCv]

On 2/22/2020 at 3:32 PM, MrPix said:

This is frustrating. The documentation out there said both ways. You have credibility, though. Rando documents on the internet - not so much. I haven't found an official Coleco document that describes the mechanism.

I understand that the whole byte at 42h selects a 64K page to be addressed, subject to the configuration of the bottom nybble at 60h? Thus only 64K blocks can be paged, subject to the Adam's "master decoder" configured by 60h?

If that's correct, extending this system will be much easier than I thought.

Question: is it possible to disable the Z80A's interrupt/auto refresh function, if only SRAM or self-refresh DRAM were fitted?

Wow, how'd I miss this when it was posted?
I looked at the Adamem emulator for details on how that bank switching stuff worked.  The byte that is two sets of bits to determine the function of the upper and lower blocks seems to be part of the MMU, though I don't have any actual design documents to show that.  The upper memory paging scheme seems to be completely up to the expansion card implementer, other than the convention that existing software already uses.

 

Unfortunately, I don't know if the DRAM refresh can be disabled, but my guess is no.  After all, the goal is to design a system that gets the job done as simply is possible.  So if you plan to use DRAM, you likely wouldn't also design a method of disabling it.  Well, I guess the IBM PC was a special exception to that.  It used one of the general-purpose timer channels for the memory refresh clock, so software could technically turn off that channel.  Of course, if the software were in RAM, it would quickly crash after doing so.

 

But are you saying that the interrupt is fired for memory refresh?  That seems unhelpful.  Also, in ColecoVision mode it would have to be disabled completely, since the interrupt is then activated for the spinner control inputs.

Edited March 22, 2020 by ChildOfCv

[ChildOfCv]

15 hours ago, jblenkle said:

So refresh my memory...a daughtercard plugs into the main card? I remember the term but haven't heard it in a long time.

Yeah, daughterboard or daughter card, both refer to something that plugs into the main card.

[MrPix]

2 hours ago, ChildOfCv said:

Wow, how'd I miss this when it was posted?

Shame on you

I have it figured out. The DRAM refresh is in a hidden cycle within the normal Z80A bus cycles, so it's "free" in the timing sense. It's something I can safely ignore.

[ChildOfCv]

2 hours ago, MrPix said:

I have it figured out. The DRAM refresh is in a hidden cycle within the normal Z80A bus cycles, so it's "free" in the timing sense. It's something I can safely ignore.

Ah, so that was what you were looking for

Yeah, there is always a refresh cycle just after the first instruction code fetch on each instruction.  HALT mode also does refresh cycles.

Edited March 22, 2020 by ChildOfCv

[MrPix]

I come from the 68K world, so it is quite different.

[joltguy]

Just wanted to check in and see how this project is coming along... any news?

 

I'm very interested in this coming into existence as it seems that all older means of adding a serial port to the Adam are no longer readily available!

 

[MrPix]

It got slowed up severely by world events. Mostly, key parts I ordered from suppliers in Feb/Mar aren't here yet.

Still working on it, though  Just, nothing to report.

[joltguy]

Ok, happy to hear you're still working on it. Thanks for the quick reply!

 

[MrPix]

I’m almost there on the single board ADE card, too. The hold up there is that I incorporated some features that the ADE creator has decided to not support. I was faced with removing the features or forking the code. I’m not going to fork the code because that would harm the community.
 

The RAM card is working now. I have an 8MB card in my Adam right now. It just needs some clean-up and it’s done.

[rietveld]

On May 25, 2020 at 2:14 PM, MrPix said:

I’m almost there on the single board ADE card, too. The hold up there is that I incorporated some features that the ADE creator has decided to not support. I was faced with removing the features or forking the code. I’m not going to fork the code because that would harm the community.
 

The RAM card is working now. I have an 8MB card in my Adam right now. It just needs some clean-up and it’s done.

Are you planning a retail release?