Jump to content
IGNORED

This may cross the line... even for me. ;)


Omega-TI

Recommended Posts

I often have ideas that 'pop' into my head, sometimes after thinking about them for a couple of seconds I realize they are simply not practical, feasible or on a hardware level unacceptable to some.

 

The last one to 'pop' into my head was the thought, could the TIPI emulate and act like a RAM DISK too?

 

My (pro) thoughts:

1) The RPi has a lot of memory.

2) Is a lot faster than the TI.

3) The RPi is way more powerful than the TI, so might not be a problem.

4) The RPi is always "ON" so it would make a great RAM disk.

5) It's there already, why not exploit it?

 

My (con) thoughts:

1) This would create uninvited work for someone having to program a DSR for it.

2) It would probably require a TIPI chip upgrade, not just a software upgrade on the RPi.

3) Even if it could be emulated, would there be a bottleneck affecting performance?

4) Is it even necessary?

 

 

My (it kills it) thought:

1) If it requires a hardware modification from specs to the actual console... screw that!

This would cross the line, even for me!

 

 

Which led to another thought...

 

A small backup UPS for the RPi, (about the size of a pack of cigarettes). One would plug the power supply into this battery pack, and the other end to the Rpi. It would charge and then float the battery until the power went out, then the battery would take over keeping the Rpi powered. A power switch could even be installed.

 

Sure, it's not really necessary, but I like gadgets for my TI.

 

 

 

 

Link to comment
Share on other sites

I suspect(without having used it) that the TIPI's current disk emulation is already pretty close to RAM disk speed on the TI.

 

Experience with ye olde Horizon RAM disk tells me that the speed limit is going to be set by the TI long before the Pi starts struggling.

  • Like 2
Link to comment
Share on other sites

What ramdisk feature are you missing that you want TIPI to emulate? If referring to a Horizon ramdisk device, it is just another 'DSK' device. Doesn't TIPI already handle that and more? Maybe there is some misunderstanding about what a RAMdisk provides?

 

A horizon ramdisk is faster than a SCSI, HFDC, Floppy, etc. so comparatively, it will likely be faster than tipi.

Link to comment
Share on other sites

What ramdisk feature are you missing that you want TIPI to emulate? If referring to a Horizon ramdisk device, it is just another 'DSK' device. Doesn't TIPI already handle that and more? Maybe there is some misunderstanding about what a RAMdisk provides?

 

A horizon ramdisk is faster than a SCSI, HFDC, Floppy, etc. so comparatively, it will likely be faster than tipi.

 

I was thinking that while the SD card accesses things faster than a floppy, accessing the SD card might be a 'slow down down point'. If the programs were in 'active memory' of an emulated RAMDISK in the Rpi, could that speed things up just a tad bit more? Granted I don't know how much, or if it would even be noticeable, it was just an idea that popped into my head. You guys would know more than me.

Link to comment
Share on other sites

Hi Omega,

I think the main points here are that the IO ports on the Rpi are relatively slow compared to RAM. On the TI side it takes program execution to move the data; That would probably half the speed even if the port addr. auto updates. I am far from certain but I believe TIPI might use port addr. similar to the VDP.

  • Like 1
Link to comment
Share on other sites

 

I was thinking that while the SD card accesses things faster than a floppy, accessing the SD card might be a 'slow down down point'.

You're not WRONG about SD being much slower than the Pi's RAM, but the bottleneck still winds up being the TI anyways, so it is a moot point.

 

 

Here's my logic(and the part where I beat the problem to death with words).

 

Foundation: A bargin-bin class 4 SD card is supposed to offer, under worst-case conditions, a minimum sustained write speed of 4 megabytes per second. If we can't beat that, then SD card access is no worse than an actual RAM disk.

 

Sloppy paper-napkin estimates begin here.

3 MHz times 16 bits = copying 6 megabytes per second, assuming every two-byte copy takes one cycle(I didn't check, because it rapidly becomes irrelevant). The CPU might be able to outpace the SD card IF it could concern itself solely with moving data across a 16-bit bus and never service interrupts, read from GROM, touch VDP RAM, or hit the expansion bus.

This is already a wildly unrealistic upper boundary, but it lets us quickly define the situation. We're BARELY able to outrun a slow SD card under this generous best-case scenario.

 

But, as I said, that's quite an unrealistic situation. For starters, there's not even a kilobyte of 16-bit RAM in the system(without a somewhat involved modification that isn't currently TIPI-compatible). And once you leave that tiny handful of full-speed RAM, the 8-bit multiplexed expansion bus and wait state generator are going to keep you well south of that hypothetical upper boundary.

Even with a large pool of 16-bit RAM to work with, the SD card is still on the wrong side of that multiplexer, so we're already moving a byte every cycle instead of two bytes every cycle. That's 3 megabytes per second. We've already fallen below the threshold just by virtue of being a sidecar.

 

And then the processor starts servicing the VBlank interrupt, and now you're accessing system GROMs and VDP RAM. And... yeah, you aren't even moving 3 megabytes per second anymore. I don't know what you ARE moving, but I know that isn't it.

 

 

So in my off-the-cuff estimation, an SD card can be considered equivalent to a RAM disk, for TI storage purposes.

A 99/8, Geneve, or SGCPU user could see a benefit, but... that's not a cross most of us are going to have to bear. I think the poor souls stuck with those systems might have to pay extra for class 10 SD cards.

 

 

 

As an aside, I can't figure out a reason that the TIPI's modified Raspbian install wouldn't be doing disk caching, like every other modern OS does to improve performance and reduce wear on the storage device.

So the OS is, presumably, already working behind the scenes to give you an approximation of the authentic RAM disk experience. Ain't modern technology great?

  • Like 2
Link to comment
Share on other sites

Hi Omega,

 

I think the main points here are that the IO ports on the Rpi are relatively slow compared to RAM. On the TI side it takes program execution to move the data; That would probably half the speed even if the port addr. auto updates. I am far from certain but I believe TIPI might use port addr. similar to the VDP.

Once loaded my new RXB 32K swap using the SAMS would be instant as it only takes as long as to load memory registers 2,3,A,B,C,D,E,F and bang memory swapped and loaded, just execute that address and boom FW!

 

If TIPI is that fast than would be a very cool loader and saver method for RXB SAMS 32K swap routine.

 

Remember unlike every other concept none of them could freeze and save memory exactly as it was when you changed things..... So now you can reload where you left off.

Link to comment
Share on other sites

You could use NVRAM, but the power-up would probably trash part of the data. . .

Why? I do not think the SAMS has any memory check on startup?

 

SAMS starts off in PASS mode with Registers OFF, so only that PASS MODE memory 32K would be trashed, the rest would remain unchanged.

 

This would be no different then what we have currently, except the other 992K has programs ready to use loaded in 31 (32K) banks.

Edited by RXB
Link to comment
Share on other sites

Sloppy paper-napkin estimates begin here.

3 MHz times 16 bits = copying 6 megabytes per second, assuming every two-byte copy takes one cycle(I didn't check, because it rapidly becomes irrelevant). The CPU might be able to outpace the SD card IF it could concern itself solely with moving data across a 16-bit bus and never service interrupts, read from GROM, touch VDP RAM, or hit the expansion bus.

This is already a wildly unrealistic upper boundary, but it lets us quickly define the situation. We're BARELY able to outrun a slow SD card under this generous best-case scenario.

Don't worry, it's not even close. To start with your numbers there:

 

3MHz x 16 = 6MB/s.

But, the fastest possible memory cycle is 2 cycles, so divide by 2 for 3MB/s. (That's just the memory access cycle, not even an instruction which is 5 times that!)

All external ports are connected through the 16<->8 bit multiplexer, which wastes 4 cycles per access, so divide by 4 for 750KB/s.

You have to write the data somewhere (likely also 8 bit). Writes incur a read before write, and at 4 cycles each, let's divide by 8 again. 94KB/s.

 

That's not even considering the fastest possible loop to actually generate those memory accesses, which will require a few instructions, which at their quickest will be 8-10 cycles each. If we say 3 instructions at 8 cycles, 24 cycles per loop, then we're down to a bit under 4k/s.

 

In the end, the SD card has no problem outpacing a RAMdisk. :) My actual benchmarks back in the day managed around 2k/s.

 

(edit: as noted below, these numbers are baloney. I blame the heat, though I stand by the conclusion ;) )

Edited by Tursi
Link to comment
Share on other sites

Wasn't that more like 2k per frame - not per second?

Ah... yeah, that sounds correct. I can never find my notes. Mind you, I also miscalculated the size of the loop - that benchmark was an unrolled loop which spreads out the cost of the jump, and the move only needs to be one instruction, so you can probably get down to an average of around 10 cycles per instruction. Just feeling a bit too lazy to do the real work... ;)

 

That's why benchmarking beats napkin work every time! hehe ;)

Link to comment
Share on other sites

So in my off-the-cuff estimation, an SD card can be considered equivalent to a RAM disk, for TI storage purposes.

A 99/8, Geneve, or SGCPU user could see a benefit, but... that's not a cross most of us are going to have to bear. I think the poor souls stuck with those systems might have to pay extra for class 10 SD cards.

It is important to account for the hardware interface (for example, ramdisk card, scsi card, tipi card) between each media device and the TI. Raw media speed is a great indicator but doesn't always translate to 'faster' IO with our TI peripherals.

 

So the TI can probably - at its best - copy 32K into 0.5 seconds

Was the 2k/frame derived from vdp dsr copies? Bypassing VDP memory, as is done by certain controllers and cards, improves program load times considerably by eliminating the double copy inherent in VDP-based DSRs (i.e., once from device to VDP, then from VDP to CPU RAM). Unfortunately for compatibility purposes most programs still use vdp-based loaders and dsr calls. If Matt hasn't added CPU RAM pab/buffer extensions to his TIPI DSR, it would be a nice option IMHO.

Link to comment
Share on other sites

It is important to account for the hardware interface (for example, ramdisk card, scsi card, tipi card) between each media device and the TI. Raw media speed is a great indicator but doesn't always translate to 'faster' IO with our TI peripherals.

 

Was the 2k/frame derived from vdp dsr copies? Bypassing VDP memory, as is done by certain controllers and cards, improves program load times considerably by eliminating the double copy inherent in VDP-based DSRs (i.e., once from device to VDP, then from VDP to CPU RAM). Unfortunately for compatibility purposes most programs still use vdp-based loaders and dsr calls. If Matt hasn't added CPU RAM pab/buffer extensions to his TIPI DSR, it would be a nice option IMHO.

No, the 2k per frame was a benchmark measuring the performance copying from the cartridge port to VDP memory - but it was not a file load so there was no second copy (and so the performance would be the same to 8-bit RAM as well). That was back when I was trying to decide if playing back video at an acceptable rate was feasible. :)

 

edit: but, that's on the destination side, so it wouldn't matter whether the source was RAM or SD. :)

Edited by Tursi
Link to comment
Share on other sites

No, the 2k per frame was a benchmark measuring the performance copying from the cartridge port to VDP memory - but it was not a file load so there was no second copy (and so the performance would be the same to 8-bit RAM as well). That was back when I was trying to decide if playing back video at an acceptable rate was feasible. :)

 

I just realized that even though I typed 2k/frame I was thinking 2k/s from the earlier post in the thread. The former is certainly closer to what I was expecting as 'reality' :)

Link to comment
Share on other sites

I imagine it isn't possible to battery-back a SAMS card..

 

This might be a radical thought for most, but you could cut the traces on the SAMS board where it gets it's power from the P-Box and then feed it directly from a properly rated wall-wart plugged into your regular UPS.

  • Like 1
Link to comment
Share on other sites

I just realized that even though I typed 2k/frame I was thinking 2k/s from the earlier post in the thread. The former is certainly closer to what I was expecting as 'reality' :)

Yeah, sorry about that. That's what I get for being lazy and not double checking.

Link to comment
Share on other sites

Tursi, many thanks for the more realistic speed estimate.

 

I "knew" we weren't going near those speeds. But I lacked the hardware knowledge to make the point with anything better than those wildly optimistic numbers.

 

 

As for why...

A. if we were going that fast, it wouldn't take a visible amount of time to load Funnelweb off a Horizon. Used to do that a lot, typing homework up. Way faster than floppies, but definitely not instant.

 

B. If the 4A could move anywhere close to six megabytes a second, TI wouldn't have been in a price war with the frickin' VIC-20 back in 1981, because they would've been too busy devastating the minicomputer industry to care what Commodore was doing... or this fictional super-4A would've been cancelled to protect the 990 line's profits. Either way, no one would have been pretending the 4A and VIC-20 were on even footing. Six megabytes a second was simply too fast to be overlooked, so it obviously wasn't ever there.

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