Jump to content
IGNORED

Eliminating the 4 wait state penalty for memory mapped hardware


Recommended Posts

I was intending to start a thread for creating a new design for a memory expansion, but I have thought more about it, and I think that would be premature.  What I really want is a UNIXy operating system for the TI99/4A.  An operating system would give us the system for allocating memory and other resources that I'm looking for. 

 

I personally am not interested in the PEB SRAM based memory expansions.  They have their merits.  For instance they have far fewer timing requirements.  The timing requirements they do have are almost nonexistent, seemingly solving themselves.  Inside the console they might be the only solution I would go for in fact.  But in the TI99 PEB they are not any faster than the DRAMs, unless you apply some of Nouspikel's "Controlling the wait-state generator" mods. And as Ksarul has pointed out, they are expensive.  DRAMs are much cheaper and have greater capacities, especially when you get into memory modules.  Solving the 4 wait state per access problem is far more problematic for them, but I do have an idea that doesn't have much to do with the aforementioned Nouspikel mods.  The math works out so far, but the actual application almost always deviates from perfection.🙂 

 

I've done some schematics for SAMS to expand to 16MB.  Two add a possibility of using 48K-64K of physical memory address space.  Two provide further address decoding to provide a DSR ROM.  I'm uploading these files as an offering to anyone who wishes to continue to support a larger SuperAMS, or add DSR ROM to their own SAMS.

 

This thread is dedicated for the express purpose of creating an alternative to the zero wait state mod offered by Thierry Nouspikel's "Controlling the wait-state generator".  While Thierry did a remarkable job coming up his solution, it doesn't have a chance of satisfying the specs for reading from a 4116 DRAM, not even close, in fact.  I believe it is possible to do so without altering the 16/8 bus multiplexer(Thierry's "wait-state generator"), which I just call 16/8MUX.  My current goal is to raise the 3 MHz clock rate that governs the 32K RAS/CAS logic to 9 MHz.

 

 

16M-SAMS-(0.1).zip

Edited by hhos
Attempting to clarify the purpose of this thread
  • Like 7
Link to comment
Share on other sites

When I was originally contracted to do the layout for the first AMS by Asgard before the SAMS I designed and even layouted a full size PEB version that would combine the features of Horizon RAMBO and Myarc 128kos and AMS up to 16mb as well with a DSR ROM and RAM mapping there as well using 1B00 CRU so that the XOP and GPL opcodes could be used as well. But sadly the idea was scrapped as they only wanted a half size card and minimum cost to produce

Edited by Gary from OPA
  • Like 3
Link to comment
Share on other sites

8 hours ago, Gary from OPA said:

When I was originally contracted to do the layout for the first AMS by Asgard before the SAMS I designed and even layouted a full size PEB version that would combine the features of Horizon RAMBO and Myarc 128kos and AMS up to 16mb as well with a DSR ROM and RAM mapping there as well using 1B00 CRU so that the XOP and GPL opcodes could be used as well. But sadly the idea was scrapped as they only wanted a half size card and minimum cost to produce

What is so special about the 1B00 CRU that it would make XOP and GPL opcodes available?  Did that board design use SRAM, DRAMs, SIMMs, or other?

Link to comment
Share on other sites

8 hours ago, Gary from OPA said:

as well with a DSR ROM and RAM mapping there as well using 1B00 CRU so that the XOP and GPL opcodes could be used as well.

My 128KB Foundation card (back when I sold it in '88) had no DSR - I made my own.  I think that question has been taken out of context, nothing to do with the CRU base, but the fact that some memory cards had no DSR and his did.

 

I'll take a break here though, been a tough day.

  • Like 1
Link to comment
Share on other sites

1 hour ago, hhos said:

What is so special about the 1B00 CRU that it would make XOP and GPL opcodes available?  Did that board design use SRAM, DRAMs, SIMMs, or other?

The console ROM has by default table setup for xop and GPL opcodes not defined look for certain entries in the DSR ROM space at 1b00 as ti themselves had a debugger card that used them, so it would always be great to use that again to handle memory management of pages similar to how xop is used by mdos on geneve. Of course like you stated wait states and the whole 8bit bus and slow cru scanning in total makes it slow overall for timing when you want to be able to switch pages with as little overhead as possible but it's something that needs to be done and of course properly so they is good software support as the problem with most memory expansion has been lack of software or difficulty in using it.

 

My large scale full size PEB used SRAM, the main reason back then SRAM was popular was people were using the extra memory as Ramdisk space and SRAM runs on batteries. The only DRAM cards were foundation, Myarc, corcomp and both myarc and corcomp had options to use external 12volt as they also had options to use the space for Ramdisk but it was not very reliable for when the PEB power was off.

 

These days there less need for Ramdisk storage so the focus should be solely on program space which that was the idea of SAMS but your idea for OS as overwatch is good it might help finally see good support with others making programs that use all the space.

  • Like 2
Link to comment
Share on other sites

Specifically regarding the topic of the post, a few thoughts and opinions:

 

* There is an existing mod to remove the wait-states in the console (see Thierry's tech pages and mainbyte website).

* There is an existing mod to put the 32K on the 16-bit bus.

* There is an existing memory-mapping / paging scheme (SAMS).  A new memory mapping / paging / expansion scheme would have zero-support for any existing software.  One-off hardware is just that, one-off, and at that point you may as well just make a different computer that really does what you want.  This is a slippery slope between enhancing the 99/4A and making something new that is incompatible.

* Most people cannot mod their consoles if soldering is required, so if you care anything about sharing the results of the project, then it is going to have to be a plug-in solution.

 

The most appealing hardware enhancements tend to be those that give a quality-of-life to the original hardware, yet still allow people to enjoy the system mostly as it would have been BITD.  Getting data to/from the console is a big one.  More memory... is a slippery slope.  No one had lots of RAM (over 32K) BITD (or even now), so very little software exists that requires it.  And no one is chomping at the bit to make new software for a 99/4A that has/requires tons of banked RAM. If anyone is wanting that, then we have SAMS.

 

The system expansion thought-experiment happens pretty regularly around here, and usually ends there.  There are lots of things we *could do*, but very little makes sense or makes it to physical manifestation.

 

13 hours ago, hhos said:

What I really want is a UNIXy operating system for the TI99/4A.  An operating system would give us the system for allocating memory and other resources that I'm looking for.

 

To me, that is confusing on a limited system like the 99/4A.  In a limited resource single CPU system like the retro computers, much of the beauty and fun is being able to interact with the hardware directly, without any abstractions like an OS or memory manager.  We have newer bloated, boring, complicated computers for that.  When it comes to a retro computer, I want zero operating system getting in the way.

 

To follow the thought experiment, say you had this UNIXy OS with memory and hardware resource management, what would you do then?  The CPU would be spending most of its time managing the system, and leave very little for applications.  And the 99/4A is not exactly friendly to interrupts or supporting the few features the CPU does offer for this kind of thing (the 99/4A is neutered, we suspect so as to not compete with TI's minicomputer line using the same CPU).

 

Anyway, just my rambling, please don't take offense to anything here, it was not intended as such, just having a conversation.

 

Edited by matthew180
spelling
  • Like 13
Link to comment
Share on other sites

A souped up 4A with multitasking would still be a retro-computer -- it would be the kind that Texas Instruments would sell as a single-board 9900.  Sure, it's a fish in a different pond, but it's not entirely without software. 


A 99/4A with fast 32K, or even 64K, could easily run TI's Realtime Executive (RX) and Microprocessor Pascal.   This was meant for TM990/101 boards with maybe 32K.  RX provided both interrupt-driven and cooperative multitasking, interprocess communication, memory heap management, and other services. The assembly language and Pascal interfaces are documented. 

 

We don't have all the source to RX, but the object code exists in the Microprocessor Pascal (MPP) floppies. RX internals are well-documented in the RX book and MPP.  Other missing parts are Device-Independent IO and 2 other components. 

 

Anyway, I thought I'd throw that out there. 

 

Another inspiring OS is Xinu, which ran on a smaller PDP-11 in the 70s.   The book is pretty good. 

 

  • Like 4
Link to comment
Share on other sites

I've always wanted a 4a with a small multitaskable OS, maybe something that could sit in one of the 512k sram chips on a SAMS with battery backup, or a new memory enviroment.

This could be started from a small load in XB or from EA, to do the small mundane tasks such as copying and moving from floppy to hard disk and so forth, that could utilize a Tipi mouse or Mechatronic, or something.

This still being able to run files from the various data sources.

I believe that the Geneve, Geneve 2020, or something along the lines of a TI99/8 is the way to go in upgrading.

It would still have pretty good compatability with 4a programs and be able to use the MDOS or even could use a 'nix style OS for the next generation of users. JMO.

Edited by RickyDean
spelling
  • Like 1
Link to comment
Share on other sites

3 hours ago, RickyDean said:

I've always wanted a 4a with a small multitaskable OS, maybe something that could sit in one of the 512k sram chips on a SAMS with battery backup, or a new memory enviroment.

This could be started from a small load in XB or from EA, to do the small mundane tasks such as copying and moving from floppy to hard disk and so forth, that could utilize a Tipi mouse or Mechatronic, or something.

This still being able to run files from the various data sources.

I believe that the Geneve, Geneve 2020, or something along the lines of a TI99/8 is the way to go in upgrading.

It would still have pretty good compatability with 4a programs and be able to use the MDOS or even could use a 'nix style OS for the next generation of users. JMO.

Hey!  The BIOS I am designing for Geneve 2020 takes advantage of the supervisor/user modes of the 99105 to present a hardware abstraction layer to GPL or MDOS.

 

Its job is to be a tiny supervisor OS, while making it possible to give 100% CPU to GPL or MDOS.  As supervisor, it gets all interrupts or XOPs, then decides whether to forward them to GPL or MDOS.  So there is some overhead on those for the goal of compatibility. 

 

By masking which bits each process may change in the LS612 memory mapper, it can assign any power of 2 memory pages to a process, which is protected from the others.

 

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, OLD CS1 said:

Remember, the F18A has a 9900 CPU on-board...

 

A 100MHz 9900 CPU! 😛  But the F18A is more of a quality-of-life device, i.e. better video quality and lets you use your 99/4A with more modern monitors.  The enhancements don't prevent it from doing its basic job, but only a handful or two of programs since the F18A was released (2012) use some of the enhanced features.  Missing / crappy docs does not help though. 😩

  • Like 4
Link to comment
Share on other sites

29 minutes ago, matthew180 said:

The enhancements don't prevent it from doing its basic job, but only a handful or two of programs since the F18A was released (2012) use some of the enhanced features.

Never too late for that to change.  Jeesh... 12 years?!  Time flies when you have fun.

30 minutes ago, matthew180 said:

Missing / crappy docs does not help though. 😩

One would think after 12 years... :D

  • Like 1
  • Haha 1
Link to comment
Share on other sites

16 hours ago, FarmerPotato said:

A 99/4A with fast 32K, or even 64K, could easily run TI's Realtime Executive (RX) and Microprocessor Pascal.   This was meant for TM990/101 boards with maybe 32K.  RX provided both interrupt-driven and cooperative multitasking, interprocess communication, memory heap management, and other services. The assembly language and Pascal interfaces are documented.

Although it has its limitations, like everything, that's almost an accurate description of the p-system on the TI 99/4A.

  • Like 2
Link to comment
Share on other sites

8 hours ago, matthew180 said:

* There is an existing mod to remove the wait-states in the console (see Thierry's tech pages and mainbyte website).

* There is an existing mod to put the 32K on the 16-bit bus.

* There is an existing memory-mapping / paging scheme (SAMS).  A new memory mapping / paging / expansion scheme would have zero-support for any existing software.  One-off hardware is just that, one-off, and at that point you may as well just make a different computer that really does what you want.  This is a slippery slope between enhancing the 99/4A and making something new that is incompatible.

* Most people cannot mod their consoles if soldering is required, so if you care anything about sharing the results of the project, then it is going to have to be a plug-in solution.

*If the mod in Thierry's tech pages is "Controlling the wait-state generator" I have just finished skimming through it about 2 hours ago.  It is not the way to go if you want to be able to read from a 4116 DRAM.  Thierry's 0 wait-state has read timings of 70 nS and 83 nS.  A 250 nS 4116 RAM requires 165 nS on the CAS for reading.  That 83 nS isn't going to make it.  The 70 nS would work on a 200 nS RAM, but I think it would fall short on a 250 nS one.  It might squeak by, though.  But more than that, he tells us right out that it won't work with the 32K memory expansion.

 

*I'm not interested in putting the PEB on the 16 bit bus right now.  When you do that you have to have two of everything.  The 16/8 MUX interface in the console allows the peripheral to have just one ROM, RAM, etc.  I might try that some time, but that sounds like it would be a lot of work.  Where would I be able to get a description of that mod?

 

*If you examine the schematics you will find that two of them do not alter the CRU base used to access the 74LS612 registers.  But if you were to access them as if the CRU base was >5FC0, which is the address I selected with the other two with ROM included, you would never know the difference.  This is because the entire 8K at >4000 - >5FFF is selected by an output from the '138.  No other address decoding is done except that which is done by the 74LS612 itself for distinguishing the individual registers.  It is just 256 mirrors of 16 word memory addresses, all pointing to the same single bank of 16  12-bit registers.  Unless I've misread something in the schematic, or there is an inaccuracy in the schematic uploaded by Ksarul, this is not only true of my design, but the 1M SAMS as well.  If I'm wrong I would appreciate someone setting me straight.

 

Oh, BTW I do not have a SAMS, or any other memory expansion board, other than the 32K expansion that came in the PEB I bought 12-15 years ago.  All I know about the SAMS is from reading about it, but mostly what I can glean from analyzing the schematics.

 

In the schematics with ROMs ("ROM"  is in the name of the file I uploaded) the CRU base address is >5FC0 and there is one mirror at >5FE0.  All of the functions of the mapper are available to any software that you want to use.  The CRU base address is the only change if you wish to ignore the DSR.  A port from the SAMS to the "16M SAMS W/DSR" might only require changing "SAMREG EQU >4000" to "SAMREG EQU >5FC0".

 

*Some people will see value in it, or what it might lead to.  Everyone is allowed to make their own assessment as to cost vs. function.  If they want it they can beg or hire someone to do it for them.  These United States are still free, but even in China or Iran I think people can spend their money on a 16M SAMS(it might have to be made in China if they don't want to donate a kidney😨), if they wish.

 

HH

Link to comment
Share on other sites

On 3/2/2024 at 7:40 AM, hhos said:

*If you examine the schematics you will find that two of them do not alter the CRU base used to access the 74LS612 registers.  But if you were to access them as if the CRU base was >5FC0, which is the address I selected with the other two with ROM included, you would never know the difference.  This is because the entire 8K at >4000 - >5FFF is selected by an output from the '138.  No other address decoding is done except that which is done by the 74LS612 itself for distinguishing the individual registers.  It is just 256 mirrors of 16 word memory addresses, all pointing to the same single bank of 16  12-bit registers.  Unless I've misread something in the schematic, or there is an inaccuracy in the schematic uploaded by Ksarul, this is not only true of my design, but the 1M SAMS as well.  If I'm wrong I would appreciate someone setting me straight.

 

Oh, BTW I do not have a SAMS, or any other memory expansion board, other than the 32K expansion that came in the PEB I bought 12-15 years ago.  All I know about the SAMS is from reading about it, but mostly what I can glean from analyzing the schematics.

 

In the schematics with ROMs ("ROM"  is in the name of the file I uploaded) the CRU base address is >5FC0 and there is one mirror at >5FE0.  All of the functions of the mapper are available to any software that you want to use.  The CRU base address is the only change if you wish to ignore the DSR.  A port from the SAMS to the "16M SAMS W/DSR" might only require changing "SAMREG EQU >4000" to "SAMREG EQU >5FC0".

 

*Some people will see value in it, or what it might lead to.  Everyone is allowed to make their own assessment as to cost vs. function.  If they want it they can beg or hire someone to do it for them.  These United States are still free, but even in China or Iran I think people can spend their money on a 16M SAMS(it might have to be made in China if they don't want to donate a kidney😨), if they wish.

 

HH

The schematics for the 1M (SW99ers) and for the 1M/4M SAMS boards match the hardware, so they should point you in the right direction for analysis purposes, @hhos. As a side note, I am waiting for some daughter boards to arrive that should just plug in to the 36-pin sockets of the 2020 Edition of the board (and should also work with the 2017 Edition, but that will need some further validation due to a couple of trace changes between the versions). If everything works, an upgrade to 4M on those boards would not be too terrible (although it would probably almost double the cost of the SAMS, as the 2M chips and adapters would end up costing about $25 per chip, just in parts). It would also require over a thousand dollars in advance parts purchases, just to get everything at a reasonable cost. That is still significantly less than the Zeropower option with questionable used chips, and way less than new Zeropower chips, so it is definitely an improvement. This method also lends itself to further expansion, as I do have a schematic on my back burner that I may need to turn into a board sooner or later that would use either 8 of these or 8 of the 512K chips to build a 4M/16M full-size SAMS board. That is seriously more than anything used today, and based on availability of the 2M SRAM chips, may not even be practical. There were 240 of these chips available two weeks ago from the only source in the world that has them in stock (many others list them, but all roads lead back to this single source). As of today, there were only 120 in stock (somewhat less after I bought a few more for testing), with a notice that future replenishment could not happen prior to early September, as it is a special order item with the manufacturer.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

33 minutes ago, RXB said:

I would buy a bigger SAMS and would like up to 16Meg version for as much as $200

A 16M version would probably be closer to $350, @RXB. Just the 8 memory chips in their adapters would cost over $200 in raw parts, no assembly included. . .then you have the cost for the boards and the rest of the components that go on them and some reasonable amount for assembly/testing. That's why I noted that a 16M SAMS is probably just a very low probability item, as larger 8-bit 5V chips just aren't out there (there are larger 3.3V chips that claim TTL compatibility, but using them does increase board complexity a bit). I also found an alternate 2M chip using the same footprint as the one I'm experimenting with, but no one willing to ship to the US seems to have them in stock (I found some in India and the UAE, but nowhere else). Some other sources do identify them as "on order" though, so the status may change. Based on what I've seen though, they are coming from the same production line as the ones I'm using now--just labeled for a different company (both OEMs are Taiwanese).

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Posted (edited)

@Ksarul, there is one error on your schematic that I found, corrected on my copy of it, and promptly forgot.  The Latch Enable(LE) on the '373 chip is not an active low input.  An active high designation is also consistent with the logic from which this signal is derived.

Edited by hhos
  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...
On 2/29/2024 at 9:16 PM, hhos said:

I was intending to start a thread for creating a new design for a memory expansion, but I have thought more about it, and I think that would be premature.  What I really want is a UNIXy operating system for the TI99/4A.  An operating system would give us the system for allocating memory and other resources that I'm looking for. 

 

I personally am not interested in the PEB SRAM based memory expansions.  They have their merits.  For instance they have far fewer timing requirements.  The timing requirements they do have are almost nonexistent, seemingly solving themselves.  Inside the console they might be the only solution I would go for in fact.  But in the TI99 PEB they are not any faster than the DRAMs, unless you apply some of Nouspikel's "Controlling the wait-state generator" mods. And as Ksarul has pointed out, they are expensive.  DRAMs are much cheaper and have greater capacities, especially when you get into memory modules.  Solving the 4 wait state per access problem is far more problematic for them, but I do have an idea that doesn't have much to do with the aforementioned Nouspikel mods.  The math works out so far, but the actual application almost always deviates from perfection.🙂 

 

I've done some schematics for SAMS to expand to 16MB.  Two add a possibility of using 48K-64K of physical memory address space.  Two provide further address decoding to provide a DSR ROM.  I'm uploading these files as an offering to anyone who wishes to continue to support a larger SuperAMS, or add DSR ROM to their own SAMS.

 

This thread is dedicated for the express purpose of creating an alternative to the zero wait state mod offered by Thierry Nouspikel's "Controlling the wait-state generator".  While Thierry did a remarkable job coming up his solution, it doesn't have a chance of satisfying the specs for reading from a 4116 DRAM, not even close, in fact.  I believe it is possible to do so without altering the 16/8 bus multiplexer(Thierry's "wait-state generator"), which I just call 16/8MUX.  My current goal is to raise the 3 MHz clock rate that governs the 32K RAS/CAS logic to 9 MHz.

 

 

16M-SAMS-(0.1).zip 4.23 MB · 10 downloads

I definitely understand your dream for the UNIXy OS and all it brings. I also have a strong preference for Unix type operating systems, the C libraries, and stream-based file concepts. These are all quite possible with even 32 KB RAM and a TIPI. Prefer larger screen real estate (80 columns), then F18A gets you there. I'm sure a lot can be done with managing memory in clever ways but the paging has impacts to performance. Multi-tasking as well. And it's still a 1976 era 16 bit CPU with a 16 bit (well 15) address bus.

 

I'm not trying to dissuade you. I like you ideas. I've also pressed the boundaries on the software side creating my own Unix like variant. I enjoy the challenges and figuring out the best compromises that live within the current TI-99 state of the art hardware and ecosystem. My wife does puzzles and Mahjong and I do this.

 

I look forward to where you go! I'd be happy to get some extra performance if you can make it happen!

  • Like 2
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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