Jump to content
MrPix

"MIB4" card

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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! :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

*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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...