Jump to content
IGNORED

What's on YOUR Want & Dream List for 2020?


Omega-TI

Recommended Posts

1 hour ago, adamantyr said:

3. ROM programming means everything is static; no dynamic calculations unless you use 32K RAM and use that space for it. Also means you have to clearly designate constants from variables.

I discovered these kind of issues myself, long ago while attempting to get a game ROM to run from RAM using the MINIMEMORY cart. I imagine programming for ROMs to be an art-form of juggling lists and segments.:ponder:

  • Like 1
Link to comment
Share on other sites

1 hour ago, HOME AUTOMATION said:

...why don't we have a PAGE TABLE system for the TI?

 

With paged memory going upwards into the high Megabytes now, it seems overdo!

Well, depending on what you mean, that's essentially what the AMS and its descendants are. It makes all the RAM pagable in reasonably small chunks. It's a decent enough system with a theoretical top end of 16MB (as designed). 

  • Like 3
Link to comment
Share on other sites


Maybe I really meant VIRTUAL MEMORY...

 

From Wikipedia:

 

"A page table is the data structure used by a virtual memory system in a computer operating system to store the mapping between virtual addresses and physical addresses. Virtual addresses are used by the program executed by the accessing process, while physical addresses are used by the hardware, or more specifically, by the RAM subsystem. The page table is a key component of virtual address translation which is necessary to access data in memory.

 

In computing, virtual memory (also virtual storage) is a memory management technique that provides an "idealized abstraction of the storage resources that are actually available on a given machine"[1] which "creates the illusion to users of a very large (main) memory."[2]"


Before I came here a year ago I had very little concept of PAGING!
I have come up with a couple interdependent routines positioned at the top of each page that let different PAGES interact by transferring page #s and return addresses to and from REGISTERS and specific CPU RAM addresses used in BRANCH instruction operands.
Still, though this works well, it requires more time a memory to specify the PAGE #s and pass data through unPAGED memory.
Perhaps a seperate system would exact similar penalties.

Edited by HOME AUTOMATION
spellinin':)
  • Thanks 1
Link to comment
Share on other sites

4 hours ago, Tursi said:

Well, remember that cartridge memory is not system memory, you're still just banking 8k at a time. :)

 

Yup.  That's why you would need a shit ton of CS lines.  (Small banks == more banks needed).  If you catch 2 bytes being written (16 bit write), that is 65535 possible values to select from. Or, at a 4k window (since the cart has a ram window and a rom) that gives ~256 mbytes.  Basically like a souped up mini memory cart. It would take a pretty scary number of flip flops wired in at the bottom of the ROM area to do the catching, and the SRAMs would be pricey, but I belive it would work.

  • Like 1
Link to comment
Share on other sites

 

3 hours ago, HOME AUTOMATION said:


Maybe I really meant VIRTUAL MEMORY...

 

From Wikipedia:

 

"A page table is the data structure used by a virtual memory system in a computer operating system to store the mapping between virtual addresses and physical addresses. Virtual addresses are used by the program executed by the accessing process, while physical addresses are used by the hardware, or more specifically, by the RAM subsystem. The page table is a key component of virtual address translation which is necessary to access data in memory.

 

In computing, virtual memory (also virtual storage) is a memory management technique that provides an "idealized abstraction of the storage resources that are actually available on a given machine"[1] which "creates the illusion to users of a very large (main) memory."[2]"

 

Yeah, you're heading in the right direction with your thinking there -- virtual memory uses pages to map data into the available memory space.

 

To make it easier to explain, let's go back in time a little bit. Let's imagine a 32-bit PC running Windows 98 with 128MB of RAM - yeah, going way back. ;) 

 

Now, that PC has the ability to access 4GB of RAM, that is, it has a 4GB memory space. But, nobody can afford 4GB of RAM and the motherboard can't take it anyway. But you want more than 128MB, so here's what they do. They "virtualize" the memory space. There's hardware on the PC that manages the memory for them, such that each application /thinks/ that it has its own memory space. In Windows, the first 2GB of the address space was allocated to the software, and the second 2GB was owned by Windows.

 

Now, of course, there wasn't enough real RAM to do that, so what they did was for each page of memory that an application (or Windows) needed, Windows would set up the hardware to point to the page of REAL memory that VIRTUAL address would reference. So even though there's only 128MB of actual RAM, it's all split up across that 4GB of space to make everyone happy. Each application has it's own pieces of that memory at different PHYSICAL addresses, even though they might be the same VIRTUAL addresses in each application. 

 

Okay, so far so good? What happens when you want more than 128MB of memory? This is where virtual memory comes in. When an application asks for a specific page of its virtual memory, it might not be mapped to real memory yet. In that case, the memory controller alerts the operating system that there has been a "page exception". The operating system then finds an unused block of memory and can assign it to that virtual address for that application. But here's the clever part - since the operating system already got control, if there's no real memory left, it can go ahead, save some unused data from another area to disk, and so free up that real memory for the request. Should the owner of that original page need it back, the OS again gets notified, and can save something else off to disk, read back what it saved earlier (even to another physical page), and the application never knows the difference.

 

On the TI, the AMS follows the same basic concepts, except that the paradigm is inverted. Our memory space is only 64K, but we want to map 16MB into it. We still loosely have the concept of an application's address pointing to a different address in physical RAM, but we are doing it less to take advantage of our entire available memory space and more to squeeze more memory into it.

 

This does complicate virtual memory a little bit. When we access a memory location with the CPU, the odds are good there is actually something mapped to it, and the hardware therefore can't know whether it's the right something or needs to be swapped out. We'd have to use some kind of software to manage that paging by hand. And, since we don't really have an operating system nor do we tend to run multiple applications at once, likely it would come down to the application being run. But a clever app can easily manage this sort of thing on its own.

 

If I were a dreamer, and virtualizing the TI memory space was a requirement, I'd probably do two things. The first would be a simple piece of hardware that would detect changes in accessed memory page, and trigger a little interrupt routine that could ensure the "right" memory was swapped in at that page. The second, and harder part, would be a baseline operating system that understood this new memory paradigm, so that it could manage telling the interrupt routine what each page SHOULD be at a given point, and so that software could be written to interface with it. But it isn't something I'd actually want to do. Backwards compatibility would range from nightmare to impossible, and the amount of new software would probably not get beyond calculator and solitaire. ;)

 

The other way to do it, of course, is a new CPU with a larger address space (even if only internally), but again, this means new software to understand this concept.

 

Although I don't know the machine well, the Geneve has a lot of these pieces and pulled off pretty good compatibility. I would if IT could be updated for virtual memory with less effort and more value? ;)

 

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

2 hours ago, wierd_w said:

Yup.  That's why you would need a shit ton of CS lines.  (Small banks == more banks needed).  If you catch 2 bytes being written (16 bit write), that is 65535 possible values to select from. Or, at a 4k window (since the cart has a ram window and a rom) that gives ~256 mbytes.  Basically like a souped up mini memory cart. It would take a pretty scary number of flip flops wired in at the bottom of the ROM area to do the catching, and the SRAMs would be pricey, but I belive it would work.

Conceptually, yes. My 128MB ROM cart works fine capturing data and address lines. Traditionally TI bank switching carts use the address lines which gives 12 bits of latch. I captured another 2 bits from the data bus to prove that works. Somehow I never thought about capturing all 16 bits on a write... in theory you could get 12+8+8 = 28 bits of latch address. Times 8k (for ROM only) would be 2GB of ROM... that's nuts. ;)

 

Adding RAM adds a little complexity since we bank normally by writing to the ROM space. But if you split the space between RAM and ROM as you suggest, you COULD still get away with that. A CPLD can hold the latch, then you just need something to hold the data. Would be impressive to imagine a gig of each on a cart... ;)

Link to comment
Share on other sites

Or you just need a standard for memory allocation.

 

That would be more in line with how hardware EMS worked on XTs.  You have a handler that does the paging for you, and keeps track of allocations, and by what programs. When a program wants memory, it sends a request to the EMS handler, which then moves the window for it. It then reads on the pageframe like normal.  The program just has to be mindful to always notify the EMS handler when it wants to change the page.

 

Something similar could be done with the TI without resorting to exotic MMU implementations.

Link to comment
Share on other sites

23 minutes ago, wierd_w said:

Or you just need a standard for memory allocation.

 

That would be more in line with how hardware EMS worked on XTs.  You have a handler that does the paging for you, and keeps track of allocations, and by what programs. When a program wants memory, it sends a request to the EMS handler, which then moves the window for it. It then reads on the pageframe like normal.  The program just has to be mindful to always notify the EMS handler when it wants to change the page.

 

Something similar could be done with the TI without resorting to exotic MMU implementations.

See RAMBO. :)

 

(edit) Found a link with a description of RAMBO and other TI memory schemes over the ages. Nothing in detail, but enough to show what people were thinking through the years. ;) http://ftp.whtech.com/datasheets and manuals/Hardware/ti hardware compendium.txt

 

 

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

The idea here would be to replace the one-line assembler with the EMS routine, but otherwise give a modified mini memory cart, including the DSR.  The DSR would reference the EMS routine to handle page switching, and could provide a fantastically huge ramdisk, if the user wished.

 

alternatively, the EMS-like page routine could be called by user programs, to use the vastly expanded memory capacity for other purposes. (Such as disk based games, like the CRPG that spawned this discussion.)  OR both at the same time, since the handler baked into the cart should be able to keep track of its own allocations too, and report how much free spaces is not used, and present that to programs. (The calling program does not need to know specifically what pages in the space its memory is on, only which page that is allocated to IT it needs to access. The handler keeps the total accounting.)

  • Like 1
Link to comment
Share on other sites

Tursi,thankyou for your indulgent and insightful review, also the linked document! It knocked me out for a while, but digesting well! Wish I'd found it earlier in the year. I should have asked! 

 

Oh, and you are definitely a dreamer, as is shown in the humble array of accomplishments you've been good enough to share with us all!:cool:

 

  H.A.

  • Thanks 1
Link to comment
Share on other sites

As I see it, any paged memory system in a cartridge is a unique scheme used by the software built into that cartridge. There's the case of 512K carts that say "FinalGROM required" but as far as I know they still use the Guidry bank scheme. The cartridge port is just too limited - it can't provide the main 32K CPU RAM, except as a one-off like Tursi mentioned where you add wires. Besides, putting a peripheral on the side port is easier. 

 

There's no demand for an "operating system" or extension that allocates pages, because there is no multitasking software for the 4A. Every program takes over the full hardware.

 

SAMS Contest

 

We already have a memory standard. SAMS cards have been available or made over the past 10 years.  The AMS standard uses a mapping chip made by TI.

 

What if we had an AMS contest in 2020? for hardware or software that use the AMS standard?

 

So far, adamantyr is winning :)

 

 

  • Like 3
Link to comment
Share on other sites

24 minutes ago, FarmerPotato said:

SAMS Contest

 

We already have a memory standard. SAMS cards have been available or made over the past 10 years.  The AMS standard uses a mapping chip made by TI.

 

What if we had an AMS contest in 2020? for hardware or software that use the AMS standard?

 

So far, adamantyr is winning :)

 

 

I agree, SAMS is definitely established. And people could write entries in RXB or fbForth, both of which have SAMS support. Assembly language is a BIT of a tricky area; I had to kludge together my own solution for that.

 

 

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

1 hour ago, adamantyr said:

I agree, SAMS is definitely established. And people could write entries in RXB or fbForth, both of which have SAMS support. Assembly language is a BIT of a tricky area; I had to kludge together my own solution for that.

 

TurboForth has SAMS support, as well. In fact, that is the source of what I ported to fbForth. @Willsy(Mark Wills) developed a library for easily using SAMS to extend the TurboForth dictionary without needing to know the details of SAMS paging with >MAP , etc. It is detailed in his article, “SAMS Programming Library for TurboForth V1.2.1:1”. I intend to port it to fbForth one of these days. |:)

 

...lee

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

By the way, Intel's solution to expand the 16-bit architecture to use a 20-bit address space was to introduce "segment registers" whose values were added to the logical address. In detail, the segment must be shifted by one hex digit to the left, and then the logical address was added. This leads to a notation like 3120:A000, which refers to the physical address 3B200. It was an earlier concept (at least in the Intel world) than the memory virtualization that Tursi described.

  • Like 2
Link to comment
Share on other sites

26 minutes ago, mizapf said:

By the way, Intel's solution to expand the 16-bit architecture to use a 20-bit address space was to introduce "segment registers" whose values were added to the logical address. In detail, the segment must be shifted by one hex digit to the left, and then the logical address was added. This leads to a notation like 3120:A000, which refers to the physical address 3B200. It was an earlier concept (at least in the Intel world) than the memory virtualization that Tursi described.

It's a good one! Though I was trying to answer the question of "what is virtual memory?" ;)

 

I've often wondered if a segment register mightn't also extend the 9900 simply and easily. One thing it DOES offer is that compatibility is pretty easy. But as was noted above, we don't have a lot of demand for a centralized system. (You could really stretch it and argue that AMS gives you a segment register for every 4k of address space ;) )

 

Since the processor does identify instruction fetches, I think you could even externalize it and still have separate code and data segments... I can't remember if that pin stays in instruction mode for the arguments... Hell, all the other registers are external, why NOT the segments? ;)

 

But since AMS already exists and already has software support, it's probably more worth the focus.

 

  • Like 3
Link to comment
Share on other sites

55 minutes ago, Tursi said:

It's a good one! Though I was trying to answer the question of "what is virtual memory?" ;)

 

I've often wondered if a segment register mightn't also extend the 9900 simply and easily. One thing it DOES offer is that compatibility is pretty easy. But as was noted above, we don't have a lot of demand for a centralized system. (You could really stretch it and argue that AMS gives you a segment register for every 4k of address space ;) )

 

Since the processor does identify instruction fetches, I think you could even externalize it and still have separate code and data segments... I can't remember if that pin stays in instruction mode for the arguments... Hell, all the other registers are external, why NOT the segments? ;)

 

But since AMS already exists and already has software support, it's probably more worth the focus.

 

The 990 had a Memory Management module that added 3 segment registers to a process, but not to expand memory, rather to give each process up to 64K of its own protected memory in a 1 megabyte space.  The vestiges are the 99/4 assembler support for LMM, LDS,LDD. 
 

IAQ is used in the 990/189 board to synchronize the release in hardware of a one-shot NMI with a 9900. A problem you solved in software. 

 

9900 doesn’t identify arguments fetched with IAQ. Only the 99000 lets you separate code and data space through bus status codes. 
 

 

 

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