Jump to content

Photo

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


26 replies to this topic

#1 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,242 posts
  • Location:워싱턴 주

Posted Fri Jul 6, 2018 10:41 AM

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.

 

 

 

 



#2 JB OFFLINE  

JB

    Quadrunner

  • 9,216 posts
  • With Stereo-Of-The-Art-Sound

Posted Fri Jul 6, 2018 4:53 PM

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.

#3 InsaneMultitasker ONLINE  

InsaneMultitasker

    River Patroller

  • 2,120 posts

Posted Fri Jul 6, 2018 5:06 PM

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.



#4 arcadeshopper ONLINE  

arcadeshopper

    River Patroller

  • 3,392 posts
  • Location:Portland, Oregon USA

Posted Fri Jul 6, 2018 5:42 PM

pretty much a tipi is a ramdisk..since its sdcard storage you already have your dream.. 



#5 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • Topic Starter
  • 12,242 posts
  • Location:워싱턴 주

Posted Fri Jul 6, 2018 6:27 PM

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.



#6 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Space Invader

  • 46 posts

Posted Fri Jul 6, 2018 8:34 PM

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.



#7 jjh76 OFFLINE  

jjh76

    Chopper Commander

  • 143 posts
  • Location:Saint Paul, MN

Posted Fri Jul 6, 2018 9:01 PM

There are already UPS solutions available for the PI, with versions ranging from simple AA/AAA battery packs, to ones that use lithium batteries with fancy recharge and shutdown control options



#8 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 9,782 posts
  • Location:Hustisford, WI

Posted Sat Jul 7, 2018 1:46 AM

ROS and Funnelweb. :)

Just cool on original hardware.

#9 JB OFFLINE  

JB

    Quadrunner

  • 9,216 posts
  • With Stereo-Of-The-Art-Sound

Posted Sat Jul 7, 2018 2:35 AM

 

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?



#10 RXB OFFLINE  

RXB

    River Patroller

  • 3,146 posts
  • Location:Vancouver, Washington, USA

Posted Sat Jul 7, 2018 10:04 AM

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.



#11 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 9,782 posts
  • Location:Hustisford, WI

Posted Sat Jul 7, 2018 10:18 AM

I imagine it isn't possible to battery-back a SAMS card..
  • RXB likes this

#12 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,671 posts

Posted Sat Jul 7, 2018 11:06 AM

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



#13 RXB OFFLINE  

RXB

    River Patroller

  • 3,146 posts
  • Location:Vancouver, Washington, USA

Posted Sat Jul 7, 2018 12:18 PM

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, Sat Jul 7, 2018 12:21 PM.


#14 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,118 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jul 7, 2018 12:56 PM

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, Sat Jul 7, 2018 1:23 PM.


#15 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,778 posts
  • Location:Denmark

Posted Sat Jul 7, 2018 1:12 PM

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

 

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



#16 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,118 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jul 7, 2018 1:21 PM

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 ;)

#17 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,778 posts
  • Location:Denmark

Posted Sat Jul 7, 2018 1:52 PM

So the TI can probably - at its best - copy 32K into 0.5 seconds and a cheap SD card can do it about 100 times faster. But how long time does it take the TIPI to load a big E/A#5 program?


  • RXB likes this

#18 arcadeshopper ONLINE  

arcadeshopper

    River Patroller

  • 3,392 posts
  • Location:Portland, Oregon USA

Posted Sat Jul 7, 2018 2:36 PM

easy to test.. lets agree on a program and I'll verify the speed on a PI3b and someone with a horizon can do the same  .. the PizeroW will be slower no matter what as it's single core

 

Greg



#19 InsaneMultitasker ONLINE  

InsaneMultitasker

    River Patroller

  • 2,120 posts

Posted Sat Jul 7, 2018 3:52 PM


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.



#20 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,118 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jul 7, 2018 4:26 PM

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, Sat Jul 7, 2018 4:27 PM.


#21 InsaneMultitasker ONLINE  

InsaneMultitasker

    River Patroller

  • 2,120 posts

Posted Sat Jul 7, 2018 4:42 PM

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'  :)



#22 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • Topic Starter
  • 12,242 posts
  • Location:워싱턴 주

Posted Sat Jul 7, 2018 5:16 PM

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.


  • RXB likes this

#23 jedimatt42 ONLINE  

jedimatt42

    Stargunner

  • 1,655 posts
  • Location:Beaverton, OR

Posted Sat Jul 7, 2018 5:18 PM

TIPI transfer to VDP disk buffers is typically 6k/sec.

-M@

#24 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,118 posts
  • HarmlessLion
  • Location:BUR

Posted Sat Jul 7, 2018 7:32 PM

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.

#25 JB OFFLINE  

JB

    Quadrunner

  • 9,216 posts
  • With Stereo-Of-The-Art-Sound

Posted Sat Jul 7, 2018 7:38 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users