TAQOZ can copy its runtime image to _BOOT_P2.BIX for instance and automatically boot from there. In fact you would load extras into TAQOZ and then save it.
Another thing about having TAQOZ in ROM is that for instance if you had a P2 and no PC, so therefore no tools, you can still write meaningful software and also tools such as assemblers etc. In fact I have the basis for a P2ASM that runs in TAQOZ so therefore it is possible to use a P2 to develop code for a P2. If it turns out that I can squeeze video graphics into the ROM along with at least PS/2 if not USB keyboard support then you have all the basics. This is not to say that you wouldn't compile Blockly or Spin or C code etc on your PC and download this into a P2 since that would be the way I would expect most would develop code. But P2 can be a PC2 (PC too).
The SD booter first reads the MBR looking for a signature - there are two signatures - one gives a sector address and length that will load data and then run it - the other just loads the MBR sector and executes it from the long at offset $80. If the signature is not present, then the VOL sector is located and read and the same process occurs. If neither MBR or VOL have the correct signatures, then the FAT is searched for the two files to load and run. This has all been described before.
So, if the SD is not formatted as FAT32, then the MBR boot sequence must be used, otherwise it will fail.
It is a simple matter of writing a PASM JMP #TAQOZ into the MBR at offset long $80 and the relevant signature at the correct location. Then TAQOZ will come up. The only thing here is that you would need to know what the serial baud will be, so it would be necessary to initialise the crystal and frequency too.
Much simpler to just type the 3 characters "> " and <escape> which autobauds and runs TAQOZ.
What skin is it off your nose? I'm not understanding the resistance to having something instead of nothing.
Hey Peter, No skin off of my nose.
I got nothing wrong with TAQOZ. I think your work is wonderful.
I was just thinking that targeting something like VGA is really user specific.
Personally for what it's worth, I'll more likely use HDMI, I never used VGA even on the Prop1.
I just think something burned to ROM should be simple, solid and stable.
If we apply the same logic that says "why bake it in" then why have TAQOZ at all?
TAQOZ can be used to quickly test hardware, load stuff and provide debugging. That's awesome! : ]
But super complex TAQOZ with Video out, Picture Viewer, Windowing, File navigation. Networking, Wave playing, or other complex features like that... sound more like a micro OS.
And something like that people will want to modify to work with HDMI, audio out on different pins. weird combinations of PLL, Clock in. Add Mp3 and Jpeg support to the file commandline utilities.
And with anything like that baked into a tiny little unchangeable ROM, it'll become quickly outdated at the rate we all move and modify each others code around here.
Which is why I think less is more! : ]
A cool little micro OS with the latest graphics drivers, sound support, HDMI, etc. could be booted from a cheap $2.50 eeprom or SD card and updated regularly by the community which is not limited to fit in just 16k/32k/64k.
That's my thought processes, not sure if I'm way off base though or if I'm over looking some critical point.
In fact I have the basis for a P2ASM that runs in TAQOZ so therefore it is possible to use a P2 to develop code for a P2. If it turns out that I can squeeze video graphics into the ROM along with at least PS/2 if not USB keyboard support then you have all the basics.
Maybe I'm missing something obvious but right now I can only see benefit of having all this extra keyboard and video support put into the ROM if you want to boot up and control/debug/assemble/compile things by running completely standalone without even needing a external terminal attached at all, which I guess could be cool. However if you also still need an external terminal to enter this state or need to go read the boot image from flash or SD to get to that point then wouldn't this keyboard and video console support be somewhat redundant or could just be read in from that image anyway, right?
What is the most minimalistic dev system we are talking about here? Is there scope now for a totally flashless/SD less/ terminal-less (!) system coming up with PS/2 (or even USB) and video at boot time? Like the old 80's machines booting right into their BASIC environment with keyboard and video control from ROM. That could be compelling but probably more complex to auto detect and fit into the ROM and coordinate with boot pull ups etc. Might be far too hard in a short timeframe.
The problem with everything in ROM for a standalone system is that we will all want different peripherals. In the 80's we only had composite monochrome video.
Now there is going to be valid arguments for HDMI, VGA, composite video for NTSC and/or PAL or monchrome, plus various LCD panels too. How do we determine what needs to run?
So, IMHO, we are better off to load a self-contained OS from FLASH or SD. This way, the user can pre-determine what he wants, or at least how to select what options he wants.
Peter's TAQOZ is brilliant. He will tweek it a little for the respin ROM. But I don't think we need a full terminal emulation in-built.
It is quite easy for us to put a file "_BOOT_P2.BIX", with "_BOOT_P2.BIY" as a backup, on to your SD card and plug it in and boot. Whatever is in that file is up to the user... TAQOZ, Super-TAQOZ, DOS, CPM, etc, etc.
Currently, using the P2D2 with beta silicon, having an (micro) SD card plugged in with that file(s) on the card, the P2 will auto-boot from that file. It just works
The only bug is that of the P59 pull-down detection, which is solved with a small capacitor on the pin.
Currently, using the P2D2 with beta silicon, having an (micro) SD card plugged in with that file(s) on the card, the P2 will auto-boot from that file. It just works
How long does it take from the end of the reset edge to when the first application that can be read off the SD card or flash starts and can toggle a pin, has anyone timed it yet on the real P2 silicon? I guess it may depend on the size of the application and maybe clock freq's too, but ballpark...? I know it was intended to be plenty fast, did it live up to it in the real world test?
Currently, using the P2D2 with beta silicon, having an (micro) SD card plugged in with that file(s) on the card, the P2 will auto-boot from that file. It just works
How long does it take from the end of the reset edge to when the first application that can be read off the SD card or flash starts and can toggle a pin, has anyone timed it yet on the real P2 silicon? I guess it may depend on the size of the application and maybe clock freq's too, but ballpark...? I know it was intended to be plenty fast, did it live up to it in the real world test?
No idea as I don't have any way to time it.
Of course, it depends on the file length too. I have a file that does a drvnot to an led pin that is only 4 longs in length so that only one file sector will be read.
CON
_greenled = 0 ' 1=ON
DAT
orgh 0
org 0
entry
.loop drvnot #_greenled ' GREEN
waitx delay
jmp #.loop
delay long $2_000000 ' ~2*16MHz
And boot time would be faster if this code were in the MBR sector (0) with the signature long.
I guess you could use a P1 to test from reset in rising edge to P2 pin output, but you'd need a couple of wires, maybe a resistor or two for safety/pull ups etc.
P1 had the SPIN interpreter in ROM. There were both advantages and disadvantages to this.
Advantage:
Fixed known stable interpreter
Disadvantage:
Fixed interpreter
In 2008, I wrote a faster spin interpreter that had otherwise identical features.
In the process, I included an optional debugger and single-stepper.
It didn't gain any traction. There were other features that would have been nice to have, such as in-line LMM PASM. But no users = no development.
Some of you may have used it without realising it - the P1V had a ROM release that included my faster spin interpreter.
I'm mainly talking about the case where you don't have FAT on your SD card, or the less likely case where you do have FAT but not MBR (e.g. GPT). Even though it is very simple, FAT is frankly a terrible filesystem. It would be nice if we weren't restricted to only booting from FAT.
Suppose you had some filesystem other than FAT. It's possible that the code necessary to find and boot a file from it won't fit in the MBR as PASM but will as TAQOZ bytecode. So, you could put a jump to TAQOZ at the beginning, but use a different entry point or set some flags beforehand to tell it to run the rest of the MBR instead of entering interactive mode. The TAQOZ bytecode in the rest of the MBR would configure the crystal and such, define some words to help with reading whatever filesystem it's reading, and then use those words to find the file it wants to boot.
I want some lightweight log-structured or otherwise journaled filesystem that can survive losing power in the middle of any operation, since the P2, like the P1, is likely to be used in situations where it could lose power at any time. FAT certainly doesn't do anything like journaling.
Suppose you had some filesystem other than FAT. It's possible that the code necessary to find and boot a file from it won't fit in the MBR as PASM but will as TAQOZ bytecode. So, you could put a jump to TAQOZ at the beginning, but use a different entry point or set some flags beforehand to tell it to run the rest of the MBR instead of entering interactive mode. The TAQOZ bytecode in the rest of the MBR would configure the crystal and such, define some words to help with reading whatever filesystem it's reading, and then use those words to find the file it wants to boot.
In that scenario, one would be much more likely to roll their own 2nd + 3rd stage bootloader than use TAQOZ, I would think.
Suppose you had some filesystem other than FAT. It's possible that the code necessary to find and boot a file from it won't fit in the MBR as PASM but will as TAQOZ bytecode. So, you could put a jump to TAQOZ at the beginning, but use a different entry point or set some flags beforehand to tell it to run the rest of the MBR instead of entering interactive mode. The TAQOZ bytecode in the rest of the MBR would configure the crystal and such, define some words to help with reading whatever filesystem it's reading, and then use those words to find the file it wants to boot.
In that scenario, one would be much more likely to roll their own 2nd + 3rd stage bootloader than use TAQOZ, I would think.
But you can't if there's no FAT partition. You need to search for, load, and boot an image with only 446 bytes of MBR. Since TAQOZ is much denser than PASM, it would be much easier to do it in TAQOZ than in PASM.
The only thing that what I propose would require is that TAQOZ has an entry point that tells it to run bytecode at some location instead of entering interactive mode like it normally does. I suspect that if it doesn't have an explicit one now, it should be possible to trick it into doing this. It would also be nice, but not necessary, if TAQOZ made it easy to compile and store some words into the MBR and prepend the necessary PASM header to make the MBR jump to this TAQOZ bytecode on start.
But the non-trivial code might fit in the MBR as TAQOZ, even though it won't fit as PASM. Writing to a journaled filesystem might be tricky, but reading it isn't all that hard as long as it wasn't unmounted somewhere ugly, i.e. while rewriting the boot image, requiring a journal replay before the boot image can be read properly.
I don't want to require niche and sophisticated file system support. I want to allow it. All that is required for this is a way to launch TAQOZ in a non-interactive mode from PASM running out of the MBR, giving it a pointer to bytecode in hubram that it should run. Nothing in Cluso's SD booter has to be changed, since it can already run PASM out of the MBR, which can load TAQOZ itself. I suspect TAQOZ could probably be hacked by the MBR PASM to allow this, but that would use more precious MBR space.
Also, all of the cases in which the dirty journal problem is a problem also apply to FAT; FAT can only be worse. An interrupted write of the boot image that allocates new clusters will cause boot to fail for either FAT or a journalled filesystem. The difference is that replaying the journal on a journalled FS will fix the problems, whereas running fsck on a FAT filesystem will take a while and then leave the filesystem in an integral state but not necessarily the state before or after the failure.
OK, I'll take a look at TAQOZ's entry point when I get the chance, but I can't really test it until I get a P2. Maybe I could give somebody an SD card image to try, although it sounds like it would be a pain getting it to work in a reasonable number of tries through such an indirect means of testing. I imagine it's possible to do it all from the current version of TAQOZ now, though it might be a pain to hack TAQOZ into starting in a non-interactive mode.
Just use the second MBR signature which gives a raw sector address and length. Code can be up to 496KB in length and located anywhere on the SD without any knowledge of the FAT used (if any) and without any knowledge of TAQOZ. I would expect the boot code (a file as a block of sectors) could be created from any P2 supported language.
Just use the second MBR signature which gives a raw sector address and length. Code can be up to 496KB in length and located anywhere on the SD without any knowledge of the FAT used (if any) and without any knowledge of TAQOZ. I would expect the boot code (a file as a block of sectors) could be created from any P2 supported language.
But that requires the MBR to be rewritten every time the file moves or for the file not to move when rewritten, and requires that all parts of the file be consecutive. The first of these isn't practical and the second two aren't safe assumptions on journalled filesystems. For deploying applications via SD card to somebody with no special P2 software, it'd be much easier to just give them a blob of data they can send out the serial port that will start TAQOZ and have it compile a bootloader and write it into the MBR, and then let them plop files on the SD card and have the MBR TAQOZ bootloader find it.
When I get a P2, I'll experiment with putting a bootloader in the beginning of the MBR that tricks TAQOZ into running TAQOZ bytecode embedded in the MBR instead of entering interactive mode.
Just use the second MBR signature which gives a raw sector address and length. Code can be up to 496KB in length and located anywhere on the SD without any knowledge of the FAT used (if any) and without any knowledge of TAQOZ. I would expect the boot code (a file as a block of sectors) could be created from any P2 supported language.
But that requires the MBR to be rewritten every time the file moves or for the file not to move when rewritten, and requires that all parts of the file be consecutive. The first of these isn't practical and the second two aren't safe assumptions on journalled filesystems. For deploying applications via SD card to somebody with no special P2 software, it'd be much easier to just give them a blob of data they can send out the serial port that will start TAQOZ and have it compile a bootloader and write it into the MBR, and then let them plop files on the SD card and have the MBR TAQOZ bootloader find it.
When I get a P2, I'll experiment with putting a bootloader in the beginning of the MBR that tricks TAQOZ into running TAQOZ bytecode embedded in the MBR instead of entering interactive mode.
By all means experiment and find out. I found out a long time ago that unless I am running a Windows O/S off the SD card itself to capacity, that in practice fragmentation is not an issue. Anyway the minimum cluster size is typically 32kB but nonetheless I have very large files and certainly wav files of 100MB and image files and I can just read them without worrying about or every encountering fragmentation. I'm also very sure that if I wanted to I can easily scan the fat for fragmentation and defrag that file but so far after many years I have never needed to. There is also nothing stopping you from implementing your own file system with a 4GB FAT32 file and that way at least you are able to use the card in a PC. You could copy FAT32 files across and then your P2 could copy those files into the 4GB filesystem. I hate MS FAT as much as the next guy but I use it the way I want to and be practical at the same time.
Just use the second MBR signature which gives a raw sector address and length. Code can be up to 496KB in length and located anywhere on the SD without any knowledge of the FAT used (if any) and without any knowledge of TAQOZ. I would expect the boot code (a file as a block of sectors) could be created from any P2 supported language.
But that requires the MBR to be rewritten every time the file moves or for the file not to move when rewritten, and requires that all parts of the file be consecutive. The first of these isn't practical and the second two aren't safe assumptions on journalled filesystems. For deploying applications via SD card to somebody with no special P2 software, it'd be much easier to just give them a blob of data they can send out the serial port that will start TAQOZ and have it compile a bootloader and write it into the MBR, and then let them plop files on the SD card and have the MBR TAQOZ bootloader find it.
When I get a P2, I'll experiment with putting a bootloader in the beginning of the MBR that tricks TAQOZ into running TAQOZ bytecode embedded in the MBR instead of entering interactive mode.
Nothing stopping you from doing that.
You could write with TAQOZ, or any program you download for that matter, to the SD. You can write to the same address, or different, which will not or will require an MBR re-write.
BUT, there is no reason to make it a TAQOZ program, or any other language for that matter. As long as it executes a few P2 PASM instructions you are good to go without any changes to the current ROM.
FWIW, the microSD that I am mostly using for testing on the P2 is a no-brand (MIXO) 8GB SDHC U1 formatted as FAT32.
As well as the P2 files and MBR & VOL code, I also have my P1 OS and ZiCog plus CPM2.2 on this card. The CPM has 8 x 32MB FAT32 files. These 8 files each represent one CPM 8MB HDD formatted as CPM disks - ie there are many CPM files stored on each of these drives (files). I have a P1 program that can read/write these CPM drives/files and copy to/from FAT32 files, or the serial port. The FAT32 files, which includes my P2 boot files, can be read/written with Windows 10 on my laptop.
To test the real P2 silicon, I just copied a new "_BOOT_P2.BIX" file to the SD on my laptop, installed it on my P2D2, and booted P2D2. It just worked straight off
So, I think what I'm trying to ask is mainly this: is there an easy way to start TAQOZ in a non-interactive mode, giving it initial pointers to start at instead of the default? If not, can this be added if other changes to the ROM are also made?
The reason I want to use TAQOZ for this is that when the MBR is run by Cluso's SD booter, the TAQOZ engine is already resident in RAM because it was loaded from ROM with everything else. Since TAQOZ bytecode is more compact than PASM, more functionality could be had from the small space available for bootloader code in the MBR by putting a TAQOZ program there instead of a PASM program. It can really only be PASM or TAQOZ, as there isn't room for anything else, and there wouldn't be room for TAQOZ if it weren't already in ROM.
Peter:
I understand that FAT is normally used and that it is quite practical to do so. But why should we lock ourselves in to the ugliness that is FAT when we could add the possibility to use something else with only a few PASM instructions (a non-interactive entry point into TAQOZ wherein you specify your own bytecode start pointer) and maybe a few TAQOZ words to facilitate compiling TAQOZ words into the MBR?
Tachyon normally has an autorun vector that the use can set to point to their code but because TAQOZ itself does not run automatically so then there is no real need for this. However, it is just as easy to recompile a version that is then loaded onto the SD card as a boot file.
The next version may include an autorun vector because it is handy if we save TAQOZ to a boot file. I'm playing with lots of options at the moment and I don't expect to have any more ROM memory than I do now, so my options are extremely limited, but I explore nonetheless.
Could it be handy to be able to enter TAQOZ non-interactively (ie. automatically from pullup options) without the need for an SD card to be present to boot from? Perhaps that case only really makes sense if there was some PS/2 and VGA console capability already built into the ROM and you didn't want the serial port. Or in this case you just boot something else directly from flash with console IO support already included.
I'm still very interested to hear how long flash boot takes if anyone can get it going on P2. I visited Tubular and Ozpropdev yesterday and they indicated it takes 6s to boot P2 directly from SD, but that it can be made faster if you create multi-stage bootloaders etc, so hopefully sub second booting is doable.
Could it be handy to be able to enter TAQOZ non-interactively (ie. automatically from pullup options) without the need for an SD card to be present to boot from? Perhaps that case only really makes sense if there was some PS/2 and VGA console capability already built into the ROM and you didn't want the serial port. Or in this case you just boot something else directly from flash with console IO support already included.
I'm still very interested to hear how long flash boot takes if anyone can get it going on P2. I visited Tubular and Ozpropdev yesterday and they indicated it takes 6s to boot P2 directly from SD, but that it can be made faster if you create multi-stage bootloaders etc, so hopefully sub second booting is doable.
Yes, that could be a good idea and one I'd like to see. That might mean passing control to TAQOZ in the event that serial, Flash, and SD boot fail. TAQOZ can read from SD very quickly even with RCFAST but routinely reads over 3MB/sec.
If I'm following Electrodude's reasoning correctly, then the problem with 'just as easy to recompile a version that is then loaded onto the SD card as a boot file.' is that the current ROM content requires the card to be formatted as FAT32 (at least one small partition) to hold that image, or the data be located at a known offset.
While a pure PASM2 program that would fit in MBR could load from a different filesystem, the space to accommodate such fs code may not be sufficient. The second option of sector address and length also may not be suitable.
So, if the autorun vector existed, a few words of PASM2 in MBR could kick off TAQOZ at that vector and then use the following denser bytecode to bootstrap into a different (perhaps journalled) filesystem, all without ever needing FAT32.
The MBR code, and TAQOZ, could be a means to an end, with PASM2 based journalled fs code loaded to upper memory and then TAQOZ terminated to free up lower memory if that is the preference.
The autorun vector could also support another request made, of making TAQOZ callable from other code: If a standard wedge were created, to be loaded from storage with the application code, it might be able to use the autorun vector to use any standard words, as well as creating new words for specific purposes.
If I'm hearing the request correctly, it is only for the autorun vector to exist in the ROM, and the rest then lives in loaded code.
I'm still very interested to hear how long flash boot takes if anyone can get it going on P2. I visited Tubular and Ozpropdev yesterday and they indicated it takes 6s to boot P2 directly from SD, but that it can be made faster if you create multi-stage bootloaders etc, so hopefully sub second booting is doable.
Could it be handy to be able to enter TAQOZ non-interactively (ie. automatically from pullup options) without the need for an SD card to be present to boot from? Perhaps that case only really makes sense if there was some PS/2 and VGA console capability already built into the ROM and you didn't want the serial port. Or in this case you just boot something else directly from flash with console IO support already included.
I'm still very interested to hear how long flash boot takes if anyone can get it going on P2. I visited Tubular and Ozpropdev yesterday and they indicated it takes 6s to boot P2 directly from SD, but that it can be made faster if you create multi-stage bootloaders etc, so hopefully sub second booting is doable.
Yes, that could be a good idea and one I'd like to see. That might mean passing control to TAQOZ in the event that serial, Flash, and SD boot fail. TAQOZ can read from SD very quickly even with RCFAST but routinely reads over 3MB/sec.
Then why don't you make it easy to use TAQOZ, which is already resident in ROM during boot, as part of a second stage bootloader run from the MBR? I would imagine that the fastest, densest possible second-stage bootloader would involve using TAQOZ's fast SD routines that are already in RAM after ROM is loaded at initial boot, eliminating the need to load them from the SD card, and taking advantage of the TAQOZ kernel, again, already resident in RAM, to get higher code density than PASM, allowing the second-stage bootloader to take up less room on the SD card (even just the MBR should be possible for most cases).
Comments
Another thing about having TAQOZ in ROM is that for instance if you had a P2 and no PC, so therefore no tools, you can still write meaningful software and also tools such as assemblers etc. In fact I have the basis for a P2ASM that runs in TAQOZ so therefore it is possible to use a P2 to develop code for a P2. If it turns out that I can squeeze video graphics into the ROM along with at least PS/2 if not USB keyboard support then you have all the basics. This is not to say that you wouldn't compile Blockly or Spin or C code etc on your PC and download this into a P2 since that would be the way I would expect most would develop code. But P2 can be a PC2 (PC too).
So, if the SD is not formatted as FAT32, then the MBR boot sequence must be used, otherwise it will fail.
It is a simple matter of writing a PASM JMP #TAQOZ into the MBR at offset long $80 and the relevant signature at the correct location. Then TAQOZ will come up. The only thing here is that you would need to know what the serial baud will be, so it would be necessary to initialise the crystal and frequency too.
Much simpler to just type the 3 characters "> " and <escape> which autobauds and runs TAQOZ.
Hey Peter, No skin off of my nose.
I got nothing wrong with TAQOZ. I think your work is wonderful.
I was just thinking that targeting something like VGA is really user specific.
Personally for what it's worth, I'll more likely use HDMI, I never used VGA even on the Prop1.
I just think something burned to ROM should be simple, solid and stable.
TAQOZ can be used to quickly test hardware, load stuff and provide debugging. That's awesome! : ]
But super complex TAQOZ with Video out, Picture Viewer, Windowing, File navigation. Networking, Wave playing, or other complex features like that... sound more like a micro OS.
And something like that people will want to modify to work with HDMI, audio out on different pins. weird combinations of PLL, Clock in. Add Mp3 and Jpeg support to the file commandline utilities.
And with anything like that baked into a tiny little unchangeable ROM, it'll become quickly outdated at the rate we all move and modify each others code around here.
Which is why I think less is more! : ]
A cool little micro OS with the latest graphics drivers, sound support, HDMI, etc. could be booted from a cheap $2.50 eeprom or SD card and updated regularly by the community which is not limited to fit in just 16k/32k/64k.
That's my thought processes, not sure if I'm way off base though or if I'm over looking some critical point.
That's my 2 cents.
Thanks Peter. : ]
What is the most minimalistic dev system we are talking about here? Is there scope now for a totally flashless/SD less/ terminal-less (!) system coming up with PS/2 (or even USB) and video at boot time? Like the old 80's machines booting right into their BASIC environment with keyboard and video control from ROM. That could be compelling but probably more complex to auto detect and fit into the ROM and coordinate with boot pull ups etc. Might be far too hard in a short timeframe.
Now there is going to be valid arguments for HDMI, VGA, composite video for NTSC and/or PAL or monchrome, plus various LCD panels too. How do we determine what needs to run?
So, IMHO, we are better off to load a self-contained OS from FLASH or SD. This way, the user can pre-determine what he wants, or at least how to select what options he wants.
Peter's TAQOZ is brilliant. He will tweek it a little for the respin ROM. But I don't think we need a full terminal emulation in-built.
It is quite easy for us to put a file "_BOOT_P2.BIX", with "_BOOT_P2.BIY" as a backup, on to your SD card and plug it in and boot. Whatever is in that file is up to the user... TAQOZ, Super-TAQOZ, DOS, CPM, etc, etc.
Currently, using the P2D2 with beta silicon, having an (micro) SD card plugged in with that file(s) on the card, the P2 will auto-boot from that file. It just works
The only bug is that of the P59 pull-down detection, which is solved with a small capacitor on the pin.
How long does it take from the end of the reset edge to when the first application that can be read off the SD card or flash starts and can toggle a pin, has anyone timed it yet on the real P2 silicon? I guess it may depend on the size of the application and maybe clock freq's too, but ballpark...? I know it was intended to be plenty fast, did it live up to it in the real world test?
No idea as I don't have any way to time it.
Of course, it depends on the file length too. I have a file that does a drvnot to an led pin that is only 4 longs in length so that only one file sector will be read.
CON _greenled = 0 ' 1=ON DAT orgh 0 org 0 entry .loop drvnot #_greenled ' GREEN waitx delay jmp #.loop delay long $2_000000 ' ~2*16MHzAnd boot time would be faster if this code were in the MBR sector (0) with the signature long.
P1 had the SPIN interpreter in ROM. There were both advantages and disadvantages to this.
Advantage:
Fixed known stable interpreter
Disadvantage:
Fixed interpreter
In 2008, I wrote a faster spin interpreter that had otherwise identical features.
In the process, I included an optional debugger and single-stepper.
It didn't gain any traction. There were other features that would have been nice to have, such as in-line LMM PASM. But no users = no development.
Some of you may have used it without realising it - the P1V had a ROM release that included my faster spin interpreter.
Suppose you had some filesystem other than FAT. It's possible that the code necessary to find and boot a file from it won't fit in the MBR as PASM but will as TAQOZ bytecode. So, you could put a jump to TAQOZ at the beginning, but use a different entry point or set some flags beforehand to tell it to run the rest of the MBR instead of entering interactive mode. The TAQOZ bytecode in the rest of the MBR would configure the crystal and such, define some words to help with reading whatever filesystem it's reading, and then use those words to find the file it wants to boot.
I want some lightweight log-structured or otherwise journaled filesystem that can survive losing power in the middle of any operation, since the P2, like the P1, is likely to be used in situations where it could lose power at any time. FAT certainly doesn't do anything like journaling.
In that scenario, one would be much more likely to roll their own 2nd + 3rd stage bootloader than use TAQOZ, I would think.
But you can't if there's no FAT partition. You need to search for, load, and boot an image with only 446 bytes of MBR. Since TAQOZ is much denser than PASM, it would be much easier to do it in TAQOZ than in PASM.
The only thing that what I propose would require is that TAQOZ has an entry point that tells it to run bytecode at some location instead of entering interactive mode like it normally does. I suspect that if it doesn't have an explicit one now, it should be possible to trick it into doing this. It would also be nice, but not necessary, if TAQOZ made it easy to compile and store some words into the MBR and prepend the necessary PASM header to make the MBR jump to this TAQOZ bytecode on start.
That kind of file system will require non-trivial code to support anyway. No worries.
One, without the dirty filesystem support, people will need a fall back. That's the simple thing we've got now.
Since we've got that simple thing, why not just use it, and not require both niche and sophisticated file / disk system support?
Also, all of the cases in which the dirty journal problem is a problem also apply to FAT; FAT can only be worse. An interrupted write of the boot image that allocates new clusters will cause boot to fail for either FAT or a journalled filesystem. The difference is that replaying the journal on a journalled FS will fix the problems, whereas running fsck on a FAT filesystem will take a while and then leave the filesystem in an integral state but not necessarily the state before or after the failure.
That's all I got.
But that requires the MBR to be rewritten every time the file moves or for the file not to move when rewritten, and requires that all parts of the file be consecutive. The first of these isn't practical and the second two aren't safe assumptions on journalled filesystems. For deploying applications via SD card to somebody with no special P2 software, it'd be much easier to just give them a blob of data they can send out the serial port that will start TAQOZ and have it compile a bootloader and write it into the MBR, and then let them plop files on the SD card and have the MBR TAQOZ bootloader find it.
When I get a P2, I'll experiment with putting a bootloader in the beginning of the MBR that tricks TAQOZ into running TAQOZ bytecode embedded in the MBR instead of entering interactive mode.
By all means experiment and find out. I found out a long time ago that unless I am running a Windows O/S off the SD card itself to capacity, that in practice fragmentation is not an issue. Anyway the minimum cluster size is typically 32kB but nonetheless I have very large files and certainly wav files of 100MB and image files and I can just read them without worrying about or every encountering fragmentation. I'm also very sure that if I wanted to I can easily scan the fat for fragmentation and defrag that file but so far after many years I have never needed to. There is also nothing stopping you from implementing your own file system with a 4GB FAT32 file and that way at least you are able to use the card in a PC. You could copy FAT32 files across and then your P2 could copy those files into the 4GB filesystem. I hate MS FAT as much as the next guy but I use it the way I want to and be practical at the same time.
Nothing stopping you from doing that.
You could write with TAQOZ, or any program you download for that matter, to the SD. You can write to the same address, or different, which will not or will require an MBR re-write.
BUT, there is no reason to make it a TAQOZ program, or any other language for that matter. As long as it executes a few P2 PASM instructions you are good to go without any changes to the current ROM.
As well as the P2 files and MBR & VOL code, I also have my P1 OS and ZiCog plus CPM2.2 on this card. The CPM has 8 x 32MB FAT32 files. These 8 files each represent one CPM 8MB HDD formatted as CPM disks - ie there are many CPM files stored on each of these drives (files). I have a P1 program that can read/write these CPM drives/files and copy to/from FAT32 files, or the serial port. The FAT32 files, which includes my P2 boot files, can be read/written with Windows 10 on my laptop.
To test the real P2 silicon, I just copied a new "_BOOT_P2.BIX" file to the SD on my laptop, installed it on my P2D2, and booted P2D2. It just worked straight off
The reason I want to use TAQOZ for this is that when the MBR is run by Cluso's SD booter, the TAQOZ engine is already resident in RAM because it was loaded from ROM with everything else. Since TAQOZ bytecode is more compact than PASM, more functionality could be had from the small space available for bootloader code in the MBR by putting a TAQOZ program there instead of a PASM program. It can really only be PASM or TAQOZ, as there isn't room for anything else, and there wouldn't be room for TAQOZ if it weren't already in ROM.
Peter:
I understand that FAT is normally used and that it is quite practical to do so. But why should we lock ourselves in to the ugliness that is FAT when we could add the possibility to use something else with only a few PASM instructions (a non-interactive entry point into TAQOZ wherein you specify your own bytecode start pointer) and maybe a few TAQOZ words to facilitate compiling TAQOZ words into the MBR?
The next version may include an autorun vector because it is handy if we save TAQOZ to a boot file. I'm playing with lots of options at the moment and I don't expect to have any more ROM memory than I do now, so my options are extremely limited, but I explore nonetheless.
I'm still very interested to hear how long flash boot takes if anyone can get it going on P2. I visited Tubular and Ozpropdev yesterday and they indicated it takes 6s to boot P2 directly from SD, but that it can be made faster if you create multi-stage bootloaders etc, so hopefully sub second booting is doable.
Yes, that could be a good idea and one I'd like to see. That might mean passing control to TAQOZ in the event that serial, Flash, and SD boot fail. TAQOZ can read from SD very quickly even with RCFAST but routinely reads over 3MB/sec.
While a pure PASM2 program that would fit in MBR could load from a different filesystem, the space to accommodate such fs code may not be sufficient. The second option of sector address and length also may not be suitable.
So, if the autorun vector existed, a few words of PASM2 in MBR could kick off TAQOZ at that vector and then use the following denser bytecode to bootstrap into a different (perhaps journalled) filesystem, all without ever needing FAT32.
The MBR code, and TAQOZ, could be a means to an end, with PASM2 based journalled fs code loaded to upper memory and then TAQOZ terminated to free up lower memory if that is the preference.
The autorun vector could also support another request made, of making TAQOZ callable from other code: If a standard wedge were created, to be loaded from storage with the application code, it might be able to use the autorun vector to use any standard words, as well as creating new words for specific purposes.
If I'm hearing the request correctly, it is only for the autorun vector to exist in the ROM, and the rest then lives in loaded code.
Regards,
Anthony.
Then why don't you make it easy to use TAQOZ, which is already resident in ROM during boot, as part of a second stage bootloader run from the MBR? I would imagine that the fastest, densest possible second-stage bootloader would involve using TAQOZ's fast SD routines that are already in RAM after ROM is loaded at initial boot, eliminating the need to load them from the SD card, and taking advantage of the TAQOZ kernel, again, already resident in RAM, to get higher code density than PASM, allowing the second-stage bootloader to take up less room on the SD card (even just the MBR should be possible for most cases).