Of course it's slower than parallel SRAM, but fetching the bytes as required from SPI or whatever is even slower (~0.4 MT/s = 0.8 MHz Z80 (?) (altough I think the Z80 doesn't use (almost) every memory cycle like the 6502)). OTOH this amount of code
mov t1,address
shr t1,shift
and t1,mask1
mov t2,t1
add t1,cachetags_ptr
rdlong t1,t1
and t1,mask2
cmp t1,t2 wz
if_nz jmp #fetchline
and address,mask3
add address,cachedata_ptr
rdbyte data,address
ret
to read a single byte is quite a ton. (even more when writing,due to having to tag the line as dirty)
@Wuerful_21
Not sure who you arguing with/against?
I use parallel SRAM with unbuffered and seperate address and data lines directly from the propeller. Cannot get any faster than this. Just copy the address to the pins and read/write the data to another set of 8 pins, together with /CS, /WE and /OE pins.
FWIW my RamBlade uses 8 data, 19 address, plus 3 control lines (30 pins) to the SRAM.
SPI has to have the command, address and data sent (clocked) out serially. Much slower, even if quad or 2xquad is used.
Caching adds comparisons to check if the data is in cache or not, and if not then the command and address has to be sent out and then data read/written in a block.
Let us suppose I tracked down an appropriately sized SD card for the PAB I have here. How would I go about having your amazing OS install itself on the SD card, and then start when the thing is started?
To be honest I have here several Prop chips, but I haven't decided on a board target for any of them.
I have a program(s) that boot the sd card and load a default program(s).
They are in the OS release, together with source and homespun which I use to compile. There are prebuilt binaries for standard boards as well as my boards.
If you can’t find them (hard to search while on my phone) or need help just let me know.
Okay. I've downloaded the relevant ones for 1.14 so we'll see what does happen.
However your emulator links need to be updated. I tried the one for 6502 and the one for the Altair, and both gave me the not found message.
Sorry.
There are too many links that broke with a number of forum software updates for me to go back and update them all. I did update the main links in my signature.
So instead, search the forum using the description.
The main event is that it grew a VGA terminal driver:
It's an odd 32x29 characters, because that's all I could get out of a single cog...
A lot of the programs don't looks very nice in 32 columns, but it's better than nothing.
The usual VGA problem of the 64 color palette being terrible also rears its head: colors 7 and 8 are exactly the same, because there are only 2 levels of gray.
Also new is that instead of selecting between I/O drivers after the OS initialization, it now compiles a different BIN file for each I/O config (currently OS.BIN for TV+Keyboard, OSVGA.BIN for VGA+Keyboard and OSTERM.BIN for serial terminal). There is also now a fancy EEPROM bootloader aiding one in loading these:
It outputs on both VGA and composite simultaneously, displays a nice retro animation of a 3D grid and a spinning Ventilator logo, gives instructions on its usage and also has some hidden easter eggs.
Comments
Not sure who you arguing with/against?
I use parallel SRAM with unbuffered and seperate address and data lines directly from the propeller. Cannot get any faster than this. Just copy the address to the pins and read/write the data to another set of 8 pins, together with /CS, /WE and /OE pins.
FWIW my RamBlade uses 8 data, 19 address, plus 3 control lines (30 pins) to the SRAM.
SPI has to have the command, address and data sent (clocked) out serially. Much slower, even if quad or 2xquad is used.
Caching adds comparisons to check if the data is in cache or not, and if not then the command and address has to be sent out and then data read/written in a block.
To be honest I have here several Prop chips, but I haven't decided on a board target for any of them.
Of course, one can also use a bootloader to chain-load it, making it less of a hassle to update. Cluso has one somewhere, I'm pretty sure.
They are in the OS release, together with source and homespun which I use to compile. There are prebuilt binaries for standard boards as well as my boards.
If you can’t find them (hard to search while on my phone) or need help just let me know.
Posted it: see first post for link
However your emulator links need to be updated. I tried the one for 6502 and the one for the Altair, and both gave me the not found message.
There are too many links that broke with a number of forum software updates for me to go back and update them all. I did update the main links in my signature.
So instead, search the forum using the description.
VentilatorOS 2.1.0 is a thing now!
The main event is that it grew a VGA terminal driver:
It's an odd 32x29 characters, because that's all I could get out of a single cog...
A lot of the programs don't looks very nice in 32 columns, but it's better than nothing.
The usual VGA problem of the 64 color palette being terrible also rears its head: colors 7 and 8 are exactly the same, because there are only 2 levels of gray.
Also new is that instead of selecting between I/O drivers after the OS initialization, it now compiles a different BIN file for each I/O config (currently OS.BIN for TV+Keyboard, OSVGA.BIN for VGA+Keyboard and OSTERM.BIN for serial terminal). There is also now a fancy EEPROM bootloader aiding one in loading these:
It outputs on both VGA and composite simultaneously, displays a nice retro animation of a 3D grid and a spinning Ventilator logo, gives instructions on its usage and also has some hidden easter eggs.