Here is the backside of the discharge module from the ESD generator. The potting compound cracked as it aged. It causes the whole generator to malfunction. It took me awhile to find out how to contact the maker, rifling through dozens of pages telling about how they meet all of the European standards and how awesome their quality and service are and blah blah blah. Hopefully, they can actually respond to email and fix something.
Here is the backside of the discharge module from the ESD generator. The potting compound cracked as it aged. It causes the whole generator to malfunction. It took me awhile to find out how to contact the maker, rifling through dozens of pages telling about how they meet all of the European standards and how awesome their quality and service are and blah blah blah. Hopefully, they can actually respond to email and fix something.
That looks like an earlier model of the ESD3000xxx perhaps from EMC PARTNER in Switzerland! They are everything they are "cracked" up to be
I think, since SD boot time is variable, we will need to attempt it AFTER the serial window of 100ms, or start it up in another cog at the start of the serial window.
SPI flash takes a constant ~4ms, and it will receive priority.
We could abort the serial window if SD loads okay and there's a pull-up on the clock. Then, we run the SD right away. Otherwise, if there's no serial, but SD loaded okay, we run it at the end of the serial window.
You took the words right out of my mouth!
I have just been waiting for time to suggest that the serial start in one cog and looking for a download command, while in parallel another cog tries the Flash and then SD. Even if the flash/sd boots, the serial cog could remain active unless the flash/sd "booted code" stops the serial cog. This way, the serial could override the flash/sd. We need a way to do this, especially for a buggy program loaded from flash. We really want to avoid needing a link (or push button) to override the program stored in flash.
BTW I think we can share those 4 pins better between flash and sd, such that we can have both fitted if the user wants. Just that both cannot be accessed simultaneously. I need to get some time to look at this from a design point of view. We don't need this today. We need to get both flash boot code working and sd code working first. We can adjust the pins later.
PS Seems like my iPhone 6+ died in the past 2 hours
Maybe it phoned home to tell Apple I was in the shop yesterday looking at the iPhone X, but walked out empty handed. Is big brother watching me???
Tachyon is much denser than PASM if the interpreter is in ROM (like everyone has been talking about). If the second-stage bootloader that gets loaded out of sector 0 is Tachyon bytecode rather than PASM, it will be able to do a lot more with the 466 bytes before the MBR partition table. Of course, the second-stage bootloader will normally coginit itself with the payload when it's done, regardless of whether it's written in Tachyon, PASM, or something else.
What added risk is there? The SD block routines used by Tachyon would be the same PASM routines that would be used if Tachyon isn't used.
We need to be certain with minimum risk. Tachyon is still evolving.
BTW the second-stage booter will likely not coginit itself because it will use the loaded ROM bootcode as subroutines. Then it becomes a minor thing to "walk the tree" to find the ultimate file/code to load/run.
I think, since SD boot time is variable, we will need to attempt it AFTER the serial window of 100ms, or start it up in another cog at the start of the serial window.
SPI flash takes a constant ~4ms, and it will receive priority.
We could abort the serial window if SD loads okay and there's a pull-up on the clock. Then, we run the SD right away. Otherwise, if there's no serial, but SD loaded okay, we run it at the end of the serial window.
You took the words right out of my mouth!
I have just been waiting for time to suggest that the serial start in one cog and looking for a download command, while in parallel another cog tries the Flash and then SD. Even if the flash/sd boots, the serial cog could remain active unless the flash/sd "booted code" stops the serial cog. This way, the serial could override the flash/sd. We need a way to do this, especially for a buggy program loaded from flash. We really want to avoid needing a link (or push button) to override the program stored in flash.
BTW I think we can share those 4 pins better between flash and sd, such that we can have both fitted if the user wants. Just that both cannot be accessed simultaneously. I need to get some time to look at this from a design point of view. We don't need this today. We need to get both flash boot code working and sd code working first. We can adjust the pins later.
PS Seems like my iPhone 6+ died in the past 2 hours
Maybe it phoned home to tell Apple I was in the shop yesterday looking at the iPhone X, but walked out empty handed. Is big brother watching me???
Remember, though.... We've got single-cog FPGA implementations people are using.
Maybe it's better to just wait the 100ms.... Wait, that's still a problem, as it interrupts the 60-second window for when nothing bootable is found.
We really need to load the flash/SD data first, so that we can act deterministically, afterwards. What is the worst-case SD load delay? Can it even be determined?
Yes, Big Brother is looking out for you. Always your welfare at heart. He really wants to get a better look at your face.
That's what it is, Peter. What should I anticipate? I suspect just the DM1 (as shown) is bad. I imagine a new one is $1500, or so.
I suppose you could say that a used one in the box is only $1500 but you need to pay another $6000 for the box
I don't know what happened with your unit though, it really looks like it has overheated from continual charge/discharge perhaps?
That's what it is, Peter. What should I anticipate? I suspect just the DM1 (as shown) is bad. I imagine a new one is $1500, or so.
I suppose you could say that a used one in the box is only $1500 but you need to pay another $6000 for the box
I don't know what happened with your unit though, it really looks like it has overheated from continual charge/discharge perhaps?
No, it is hardly used. It's in mint condition.
The potting compound just shrunk and cracked, over time. It was last used 12 years ago and it worked perfectly then. Now, it's busted, after resting in its box all this time. It's that potting compound. The stuff was inflexible and became brittle.
I found someone selling that DM1 insert for $2200, which is probably 50x what it costs to make. The gun is now $8900. We bought it all new for $6500 back in 2004.
I think, since SD boot time is variable, we will need to attempt it AFTER the serial window of 100ms, or start it up in another cog at the start of the serial window.
SPI flash takes a constant ~4ms, and it will receive priority.
We could abort the serial window if SD loads okay and there's a pull-up on the clock. Then, we run the SD right away. Otherwise, if there's no serial, but SD loaded okay, we run it at the end of the serial window.
You took the words right out of my mouth!
I have just been waiting for time to suggest that the serial start in one cog and looking for a download command, while in parallel another cog tries the Flash and then SD. Even if the flash/sd boots, the serial cog could remain active unless the flash/sd "booted code" stops the serial cog. This way, the serial could override the flash/sd. We need a way to do this, especially for a buggy program loaded from flash. We really want to avoid needing a link (or push button) to override the program stored in flash.
BTW I think we can share those 4 pins better between flash and sd, such that we can have both fitted if the user wants. Just that both cannot be accessed simultaneously. I need to get some time to look at this from a design point of view. We don't need this today. We need to get both flash boot code working and sd code working first. We can adjust the pins later.
PS Seems like my iPhone 6+ died in the past 2 hours
Maybe it phoned home to tell Apple I was in the shop yesterday looking at the iPhone X, but walked out empty handed. Is big brother watching me???
Remember, though.... We've got single-cog FPGA implementations people are using.
Maybe it's better to just wait the 100ms.... Wait, that's still a problem, as it interrupts the 60-second window for when nothing bootable is found.
We really need to load the flash/SD data first, so that we can act deterministically, afterwards. What is the worst-case SD load delay? Can it even be determined?
Yes, Big Brother is looking out for you. Always your welfare at heart. He really wants to get a better look at your face.
Chip,
Do you really think a single cog P2 will fly ?
It's never going to compete with some of the other chips around.
Don't you think it would be at least a 2 cog minimum??? If so, this is not an issue.
Postedit:
The issue I am concerned with is the case where the user programs the flash with a buggy program that somehow locks up the P2. You need a way to run the ROM serial loader to override the flash (hopefully without changing a link).
It's not a problem with the SD card because the user can remove the card and copy a new file or loader on pc or whatever.
...
Maybe it's better to just wait the 100ms.... Wait, that's still a problem, as it interrupts the 60-second window for when nothing bootable is found.
We really need to load the flash/SD data first, so that we can act deterministically, afterwards.
It's important to have fast load pathways/choices for each of UART and FLASH sources, to cover reset-booting.
ie Pin straps should be able to use either, as fast boot.
Outside of that, user-involved loading is rather less critical, as if someone waits 166ms or 25ms does not bother them much.
Loaders themselves should have user-variable delays after RESET, to allow both reset-exit delays and device dependent boot delays to be tolerated.
If I was designing a MCU-Uart loader host, I'd issue the reset and then send a series of AutoBaud+Pings, waiting for a echo and then flip to sending, as soon as the P2 proved it was uart-awake.
That auto-compensates for any system delays, and gives the fastest possible boot in all cases.
Of course, the same repeated AutoBaud+Pings can be used with a PC host too.
Any single cog P2 is probably never going to use SD anyway, so even if it tries to coginit there is no harm done by starting up another cog at reset just to look after the SD.
@Cluso99 - Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon. The TAQOZ version of Tachyon for the P2 boot ROM is an even more compact version of the proven Tachyon kernel along with SD drivers and FAT32. I probably will end up with a bytecode version to save memory and this means that any special type of secondary bootloader can be squeezed into the MBR with room to spare. Consider TAQOZ a P2 version of OpenBoot
Any single cog P2 is probably never going to use SD anyway, so even if it tries to coginit there is no harm done by starting up another cog at reset just to look after the SD.
@Cluso99 - Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon. The TAQOZ version of Tachyon for the P2 boot ROM is an even more compact version of the proven Tachyon kernel along with SD drivers and FAT32. I probably will end up with a bytecode version to save memory and this means that any special type of secondary bootloader can be squeezed into the MBR with room to spare. Consider TAQOZ a P2 version of OpenBoot
Any single cog P2 is probably never going to use SD anyway, so even if it tries to coginit there is no harm done by starting up another cog at reset just to look after the SD.
@Cluso99 - Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon. The TAQOZ version of Tachyon for the P2 boot ROM is an even more compact version of the proven Tachyon kernel along with SD drivers and FAT32. I probably will end up with a bytecode version to save memory and this means that any special type of secondary bootloader can be squeezed into the MBR with room to spare. Consider TAQOZ a P2 version of OpenBoot
WTG Peter.
That is my hope too.
We should be able to have a number of different MBR Boot Codes for anyone willing to write one.
Meanwhile, it would be great to have a TAQOZ version in ROM that could be executed from the Serial line. Just call/jump to it by another command similar to the download or clock commands. It is interactive after all.
Good idea about just launching a second cog to investigate the SD-card situation. That cog can be launched when we fail to load good code from SPI flash.
Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon.
Ray
I believe Peter has been plotting P2 eventuality for years. Evolve???? He is all over P2 evolution
I find it kind of funny that the p2 is(will hopefully) be able to boot from a modern floppy(sd-card). As it is a trend now to reinvent the wheel, like the web browser finally is replacing the old IBM Terminals to access the cloud-computing main-frame.
So from mainframe to decentralized computing, back to the mainframe in form of cloud computing, full circle, again. Like a friend of me stated 'deja vu all over again'.
Lately I saw a Interview with Bill Gates in youtube where he stated that MS products for the Apple MacIntosh needed 14 Kb of the Apple rom resident to run. I never had a Apple MacIntosh, so I do not know much about it, but the number of 14Kb stuck with me.
@cluso99 is talking about that the second stage loader out of the MBR can a use the already initialized sd-card and also could call parts of the ROM-loaded booter/loader to utilize say serial IO and sector read from either SD or Flash, even promoting to put a MBR on the first sector of the flash to have a common approach.
I really like this. But it reminds me of something, full circle again. It was called a BIOS, way smaller and concentrated on exactly that, not blown up like BIOSes are nowadays.
So what I am talking about is that by actual plans the P2 ROM will contain serial access, flash access and hopefully sd-access. If we are really lucky even a monitor and if really, really lucky a small TACHYON kernel. And all on predefined Pins.
So lets play the game and name it BIOS. Build it that we have some sort of jump-table usable from loadable applications. Since it is RAM resident somebody NOT needing it for his application can overwrite it while loading his program. But having a common set of routines available, callable from any program written in any language makes definitely sense to me.
No need to include FullDuplexSerial into all programs, just call the existing BIOS function in RAM. Since the jump-table is in RAM one could even overwrite the destination-address with a own output routine, say to 'redirect' the standard serial output to some TV-driver and the standard serial input jmp-table entry with a PS2 driver.
So lets build a minimal IO system, say stdin, stdout, stderr, sounds familiar? Block access for sd and flash? Maybe standardized COG to COG transfers?
A big problem with the P1 was that we had different approaches to allow COG resident drivers be used by applications AND be able to replace serial against TV /Keyboard WITHOUT recompiling every time.
There where long, long threads about it but sadly it was not possible to heard the cats and get a common approach together.
But if there would be some standardized schema for character and block-access, usable with any language, things would be fine.
Even if the jump-table is not a table but a linked list to make it extensible.
The 8-bit Atari had something like this, you could write a 'driver' for a disk 'G:' or any other letter and access it like your floppies, even if you where driving a own HW-creation on the expansion port. And could use the standard BASIC commandos to access it.
OK, booting from serial or flash or sd might take a couple of more instruction when dispatched over a jmp-table, but building the ROM/RAM to support something like a common Basic Input Output System was a good Idea as someone used it first and might be a good Idea also for the P2.
And any Monitor and even TACOZ could just use this BIOS for basic IO. So If you replaced the jmp-entries for stdin and stdout to TV/Keyboard neither the Monitor nor TACOZ nor SPIN nor C nor PASM really need to know about it...
....
And any Monitor and even TACOZ could just use this BIOS for basic IO. So If you replaced the jmp-entries for stdin and stdout to TV/Keyboard neither the Monitor nor TACOZ nor SPIN nor C nor PASM really need to know about it...
One caution about the rush to add a Laundry list, is that the ROM in P2, is not memory mapped, it is only loaded into RAM at reset.
That means users cannot be certain it is still present.
If users programs are going to have to compile to (hope to) preserve some RAM area, and keep a list of calls, why not simply link in the part of 'ROM-libs' you need ?
One of the things that Chip said he would do is put in a memory protect mode for TAQOZ which I would copy to top of memory to allow other applications to be loaded from the bottom. Now, if it is in protected memory which uses a CLKSET then it can be used at runtime by any application as a BIOS. Any application that doesn't want it can unprotect it and reuse that area, no harm done.
While talking to Ray (Cluso99) about his MBR boot scheme I mentioned that I envisage a boot sequence that runs Chip's code first, if there is no serial or SPI Flash then this passes to Ray's MBR SD loader which if it fails to detect an SD card and a valid MBR boot would then pass to TAQOZ. From there we could easily enter ozpropdev's excellent monitor or just run Tachyon scripts/code. Of course TAQOZ would look for a FAT32 boot file anyway and we can switch to full speed operation as well since all booting would be relying only upon the internal 20MHZish RCO.
I will work on having something available in the next week or two that we can start playing with but I also want to have this load up automatically from SPI Flash for the FPGA version so we can test it properly.
I even did not dare to ask for loading at the end of the memory, if this is possible even better! Perfect!
And that 'protected memory' seems to be what @potatohead was asking for?
Do I understand this correctly that some top part of the memory can be write protected? That would be awesome!
If you could find some way to make BIOS calls possible to reach HUBEXEC PASM (no need for another COG) then all languages will be able to use it.
And really simple, please, over-writable vector table (or linked list, for extensibility ) for stdin,stdout,stderr,sd+flash block access or something like that.
stdin,stdout,stderr predefined with existing serial.
But I am very confident that you and chip can sort this out.
....
And any Monitor and even TACOZ could just use this BIOS for basic IO. So If you replaced the jmp-entries for stdin and stdout to TV/Keyboard neither the Monitor nor TACOZ nor SPIN nor C nor PASM really need to know about it...
One caution about the rush to add a Laundry list, is that the ROM in P2, is not memory mapped, it is only loaded into RAM at reset.
That means users cannot be certain it is still present.
If users programs are going to have to compile to (hope to) preserve some RAM area, and keep a list of calls, why not simply link in the part of 'ROM-libs' you need ?
well @jmg,
my hope here is to nail down some basics.
On the P1 we had the ROM and a fixed SPIN interpreter. Sure there are other spin interpreter, but rarely used. On the P2 this will be different.
Like you said user-programs will have to link their own libraries, SPIN2 will need a SPIN2 interpreter linked to TACHION needs its kernel and C/C++ will also link some libs. That's fine.
But if all of them could use some common basic io then things like piping may be possible, or redirection, independent of the used language.
And if you still have your ROM loaded RAM or not - hmm - its still a microcontroller, and you decide what is running, so you need to take care of that.
Imagine the P1 had a 'SOFT-ROM' so the top 32K would be RAM but preloaded with the ROM content. How often you use the SINE/COSINE tables? Perfect place for needed serial/sd / whatever buffers.
sadly its ROM.
I found the Idea of serial ROM confusing, at the beginning, but really like it now because if you need the space, but not the code, you can overwrite it.
... if it fails to detect an SD card and a valid MBR boot would then pass to TAQOZ. From there we could easily enter ozpropdev's excellent monitor or just run Tachyon scripts/code. Of course TAQOZ would look for a FAT32 boot file anyway and we can switch to full speed operation as well since all booting would be relying only upon the internal 20MHZish RCO.
I will work on having something available in the next week or two that we can start playing...
@Peter - thanks for sticking with this. I have been following this entire thread, and while some of the discussion is admittedly beyond my knowledge at the moment, my gut says your involvement in this boot ROM is crucial. Thank you again, please stay the course.
The way this will work is the top 16KB of RAM will always appear at $FC000..$FFFFF. It will be loaded from ROM on reset. A switch via CLKSET can write-protect that area.
For example, for 512KB of hub RAM:
$00000..$7BFFF = first 496KB of hub RAM
$7C000..$FBFFF = empty gap, reads $00
$FC000..$FFFFF = last 16KB of hub RAM, write-protectable (includes debug vectors at end)
I'm going to get the ROM reading away from CLKSET and have it implied for WFBYTE during cog0 cold boot. This will cut ROM loading down to 2 clocks per byte, or 32K clocks, total, which is about 1.5ms.
Comments
That looks like an earlier model of the ESD3000xxx perhaps from EMC PARTNER in Switzerland! They are everything they are "cracked" up to be
Ohh - does that mean you have silicon, and it passed all other tests ?
or is ESD what OnSemi want you to test first, as that could involve the largest re-design impact, if it misses ?
I have just been waiting for time to suggest that the serial start in one cog and looking for a download command, while in parallel another cog tries the Flash and then SD. Even if the flash/sd boots, the serial cog could remain active unless the flash/sd "booted code" stops the serial cog. This way, the serial could override the flash/sd. We need a way to do this, especially for a buggy program loaded from flash. We really want to avoid needing a link (or push button) to override the program stored in flash.
BTW I think we can share those 4 pins better between flash and sd, such that we can have both fitted if the user wants. Just that both cannot be accessed simultaneously. I need to get some time to look at this from a design point of view. We don't need this today. We need to get both flash boot code working and sd code working first. We can adjust the pins later.
PS Seems like my iPhone 6+ died in the past 2 hours
Maybe it phoned home to tell Apple I was in the shop yesterday looking at the iPhone X, but walked out empty handed. Is big brother watching me???
I want to zap the test chip we made over a few years ago, since it's almost identical to the new one.
And, yes, our ESD survivability needs to get nailed down ASAP.
We need to be certain with minimum risk. Tachyon is still evolving.
BTW the second-stage booter will likely not coginit itself because it will use the loaded ROM bootcode as subroutines. Then it becomes a minor thing to "walk the tree" to find the ultimate file/code to load/run.
Remember, though.... We've got single-cog FPGA implementations people are using.
Maybe it's better to just wait the 100ms.... Wait, that's still a problem, as it interrupts the 60-second window for when nothing bootable is found.
We really need to load the flash/SD data first, so that we can act deterministically, afterwards. What is the worst-case SD load delay? Can it even be determined?
Yes, Big Brother is looking out for you. Always your welfare at heart. He really wants to get a better look at your face.
I suppose you could say that a used one in the box is only $1500 but you need to pay another $6000 for the box
I don't know what happened with your unit though, it really looks like it has overheated from continual charge/discharge perhaps?
No, it is hardly used. It's in mint condition.
The potting compound just shrunk and cracked, over time. It was last used 12 years ago and it worked perfectly then. Now, it's busted, after resting in its box all this time. It's that potting compound. The stuff was inflexible and became brittle.
I found someone selling that DM1 insert for $2200, which is probably 50x what it costs to make. The gun is now $8900. We bought it all new for $6500 back in 2004.
No email response, yet, from them.
Chip,
Do you really think a single cog P2 will fly ?
It's never going to compete with some of the other chips around.
Don't you think it would be at least a 2 cog minimum??? If so, this is not an issue.
Postedit:
The issue I am concerned with is the case where the user programs the flash with a buggy program that somehow locks up the P2. You need a way to run the ROM serial loader to override the flash (hopefully without changing a link).
It's not a problem with the SD card because the user can remove the card and copy a new file or loader on pc or whatever.
It's important to have fast load pathways/choices for each of UART and FLASH sources, to cover reset-booting.
ie Pin straps should be able to use either, as fast boot.
Outside of that, user-involved loading is rather less critical, as if someone waits 166ms or 25ms does not bother them much.
Loaders themselves should have user-variable delays after RESET, to allow both reset-exit delays and device dependent boot delays to be tolerated.
If I was designing a MCU-Uart loader host, I'd issue the reset and then send a series of AutoBaud+Pings, waiting for a echo and then flip to sending, as soon as the P2 proved it was uart-awake.
That auto-compensates for any system delays, and gives the fastest possible boot in all cases.
Of course, the same repeated AutoBaud+Pings can be used with a PC host too.
The P1 example values given above suggest quite some variance, ( ~7:1 in just that small sample) driven by the card itself.
1GB microSD Card SD-C01G JAPAN (no brand name - came with an old phone)
Initial Boot 25ms
Second Boot 17ms
8GB microSD Card SDHC C4 SanDisk
Initial Boot 83ms
Second Boot 17ms
8GB microSD Card SDHC U1 TOHAOLL MIXZA (Taiwan) bought cheap on eBay
Initial Boot 166ms
Second Boot 9ms
64GB microSD Card SDXC C10 U1 OU (Korea) bought cheapon eBay
Initial Boot 44ms
Second Boot 8ms
@Cluso99 - Yes, Tachyon is always evolving, just like all good software should, I'm on Linux Mint 18.2 now but that doesn't mean that previous versions weren't usable. The P2 however has been "evolving" and won't be stable until it is locked into silicon. The TAQOZ version of Tachyon for the P2 boot ROM is an even more compact version of the proven Tachyon kernel along with SD drivers and FAT32. I probably will end up with a bytecode version to save memory and this means that any special type of secondary bootloader can be squeezed into the MBR with room to spare. Consider TAQOZ a P2 version of OpenBoot
WTG Peter.
That is my hope too.
We should be able to have a number of different MBR Boot Codes for anyone willing to write one.
Meanwhile, it would be great to have a TAQOZ version in ROM that could be executed from the Serial line. Just call/jump to it by another command similar to the download or clock commands. It is interactive after all.
Ray
I believe Peter has been plotting P2 eventuality for years. Evolve???? He is all over P2 evolution
EDIT: CHIP: King #1
EDIT: PETER King #2
That replacement part for my ESD gun is $2600! I wound up renting a whole different setup for $245 for a week. It should be here tomorrow.
I find it kind of funny that the p2 is(will hopefully) be able to boot from a modern floppy(sd-card). As it is a trend now to reinvent the wheel, like the web browser finally is replacing the old IBM Terminals to access the cloud-computing main-frame.
So from mainframe to decentralized computing, back to the mainframe in form of cloud computing, full circle, again. Like a friend of me stated 'deja vu all over again'.
Lately I saw a Interview with Bill Gates in youtube where he stated that MS products for the Apple MacIntosh needed 14 Kb of the Apple rom resident to run. I never had a Apple MacIntosh, so I do not know much about it, but the number of 14Kb stuck with me.
@cluso99 is talking about that the second stage loader out of the MBR can a use the already initialized sd-card and also could call parts of the ROM-loaded booter/loader to utilize say serial IO and sector read from either SD or Flash, even promoting to put a MBR on the first sector of the flash to have a common approach.
I really like this. But it reminds me of something, full circle again. It was called a BIOS, way smaller and concentrated on exactly that, not blown up like BIOSes are nowadays.
So what I am talking about is that by actual plans the P2 ROM will contain serial access, flash access and hopefully sd-access. If we are really lucky even a monitor and if really, really lucky a small TACHYON kernel. And all on predefined Pins.
So lets play the game and name it BIOS. Build it that we have some sort of jump-table usable from loadable applications. Since it is RAM resident somebody NOT needing it for his application can overwrite it while loading his program. But having a common set of routines available, callable from any program written in any language makes definitely sense to me.
No need to include FullDuplexSerial into all programs, just call the existing BIOS function in RAM. Since the jump-table is in RAM one could even overwrite the destination-address with a own output routine, say to 'redirect' the standard serial output to some TV-driver and the standard serial input jmp-table entry with a PS2 driver.
So lets build a minimal IO system, say stdin, stdout, stderr, sounds familiar? Block access for sd and flash? Maybe standardized COG to COG transfers?
A big problem with the P1 was that we had different approaches to allow COG resident drivers be used by applications AND be able to replace serial against TV /Keyboard WITHOUT recompiling every time.
There where long, long threads about it but sadly it was not possible to heard the cats and get a common approach together.
But if there would be some standardized schema for character and block-access, usable with any language, things would be fine.
Even if the jump-table is not a table but a linked list to make it extensible.
The 8-bit Atari had something like this, you could write a 'driver' for a disk 'G:' or any other letter and access it like your floppies, even if you where driving a own HW-creation on the expansion port. And could use the standard BASIC commandos to access it.
OK, booting from serial or flash or sd might take a couple of more instruction when dispatched over a jmp-table, but building the ROM/RAM to support something like a common Basic Input Output System was a good Idea as someone used it first and might be a good Idea also for the P2.
And any Monitor and even TACOZ could just use this BIOS for basic IO. So If you replaced the jmp-entries for stdin and stdout to TV/Keyboard neither the Monitor nor TACOZ nor SPIN nor C nor PASM really need to know about it...
Just a thought,
EDIT:
so its not ORG 100 but ORG 14336 ...
Mike
One caution about the rush to add a Laundry list, is that the ROM in P2, is not memory mapped, it is only loaded into RAM at reset.
That means users cannot be certain it is still present.
If users programs are going to have to compile to (hope to) preserve some RAM area, and keep a list of calls, why not simply link in the part of 'ROM-libs' you need ?
One of the things that Chip said he would do is put in a memory protect mode for TAQOZ which I would copy to top of memory to allow other applications to be loaded from the bottom. Now, if it is in protected memory which uses a CLKSET then it can be used at runtime by any application as a BIOS. Any application that doesn't want it can unprotect it and reuse that area, no harm done.
While talking to Ray (Cluso99) about his MBR boot scheme I mentioned that I envisage a boot sequence that runs Chip's code first, if there is no serial or SPI Flash then this passes to Ray's MBR SD loader which if it fails to detect an SD card and a valid MBR boot would then pass to TAQOZ. From there we could easily enter ozpropdev's excellent monitor or just run Tachyon scripts/code. Of course TAQOZ would look for a FAT32 boot file anyway and we can switch to full speed operation as well since all booting would be relying only upon the internal 20MHZish RCO.
I will work on having something available in the next week or two that we can start playing with but I also want to have this load up automatically from SPI Flash for the FPGA version so we can test it properly.
I even did not dare to ask for loading at the end of the memory, if this is possible even better! Perfect!
And that 'protected memory' seems to be what @potatohead was asking for?
Do I understand this correctly that some top part of the memory can be write protected? That would be awesome!
If you could find some way to make BIOS calls possible to reach HUBEXEC PASM (no need for another COG) then all languages will be able to use it.
And really simple, please, over-writable vector table (or linked list, for extensibility ) for stdin,stdout,stderr,sd+flash block access or something like that.
stdin,stdout,stderr predefined with existing serial.
But I am very confident that you and chip can sort this out.
Mike
well @jmg,
my hope here is to nail down some basics.
On the P1 we had the ROM and a fixed SPIN interpreter. Sure there are other spin interpreter, but rarely used. On the P2 this will be different.
Like you said user-programs will have to link their own libraries, SPIN2 will need a SPIN2 interpreter linked to TACHION needs its kernel and C/C++ will also link some libs. That's fine.
But if all of them could use some common basic io then things like piping may be possible, or redirection, independent of the used language.
And if you still have your ROM loaded RAM or not - hmm - its still a microcontroller, and you decide what is running, so you need to take care of that.
Imagine the P1 had a 'SOFT-ROM' so the top 32K would be RAM but preloaded with the ROM content. How often you use the SINE/COSINE tables? Perfect place for needed serial/sd / whatever buffers.
sadly its ROM.
I found the Idea of serial ROM confusing, at the beginning, but really like it now because if you need the space, but not the code, you can overwrite it.
Mike
YES, YES! Thanks Chip. I'm super happy.
Really great feature. Other can use this to make resident ROM type things.
@msrobots: I have been asking for that since we decided to stream ROM to RAM.
Don't care where it is. Hope it's 16k at the top of RAM. Power of 2 sized.
Hello robust ON CHIP tools.
HELP, I am infected,
MIke
@Peter - thanks for sticking with this. I have been following this entire thread, and while some of the discussion is admittedly beyond my knowledge at the moment, my gut says your involvement in this boot ROM is crucial. Thank you again, please stay the course.
and 'ozpropdev's excellent monitor' sounds like heaven to me.
Mike
For example, for 512KB of hub RAM:
$00000..$7BFFF = first 496KB of hub RAM
$7C000..$FBFFF = empty gap, reads $00
$FC000..$FFFFF = last 16KB of hub RAM, write-protectable (includes debug vectors at end)
I'm going to get the ROM reading away from CLKSET and have it implied for WFBYTE during cog0 cold boot. This will cut ROM loading down to 2 clocks per byte, or 32K clocks, total, which is about 1.5ms.
Now we've got a 1.5ms pathway from the 16KB ROM to the last 16KB of hub RAM, with a 'protect' switch we can throw:
When SETCLK D[31:29] is %001, D[28] sets 'write-protect' (does not affect clock setting)
We are ready to develop the complete ROM software now.
I will do another FPGA compile tomorrow.
Conversion to P2 should be easy as it only uses the base P1 instructions.
forums.parallax.com/discussion/167660/p1-sd-minimal-boot-test-for-p2-rom