Reviving the Vera project!

[King Harold]

Other idea: Knowing that you can swap in the same page at more than 1 place, you could execute everything in the same address space, always. Say, start at 0x4000 and have either 1 or 2 ram pages ( hm, maybe programs would like to control that, seeing as some programs need a lot of ram and other programs just have a lot of code, both is of course impossible)

But Tim, what I meant by making the thread switcher "callable" is that you could call it as though it were a "sleep(0)" call ensuring that other threads would get a chance to run - if there any (if not, the CPU time taken up doesn't bother any thread) and resetting the counter thingy used for priorities or whatever (assuming you have such a thing)

@driesguldolf: just start at 0 instead of (what is that weird address anyway?)

I believe this is the (almost)minimal OS for anyone looking to make one (it might be a good idea to initialize the hardware though)
this is 8 bytes

Code: Select all

.org 0
jp startup
.org $53  ;bootcode seems to check for this
jp startup
.db $5A,$A5
startup:
;you could initialize the hardware..
;but why would you if you're not going to use it..
;no code here - which means $FF opcodes, which is RST $38
;what would be the interrupt routine will keep calling itself

[Demon]

Maybe Vera and this project should combine forces.

Nope, he's already done all the fun stuff, and in assembly

Isn't that a good thing? There'd be less work to do, development would go by faster, and there'd be something for everyone to play with sooner.

[driesguldolf]

I just found this topic, has any progress been made? Because I really want to be in and I have alot spare of time...

If you look at the date of the first post you'll see that this thread has only existed for three days, so take it easy, cowboy ...

Lol, I thought it was posted in July...

The .orgs are to support the use of rst ##h calls, you can put some small very usefull routines there (ex. a dereferencer), ofcourse a replacement for the B_CALL() and the mode 1 isr. No idea about the port outputs (beside normal things like keyport, linkport, isr ports, apd timer ports, ...)

Hmmm, another idea is to combine ram pages and flash pages for multitasking (because dropping SMC might not be such a good idea, though most routines can be reprogrammed without it) and use $C000 - $FFFF for variable storage (as it is ment to because you can't execute code there), though 16Kb might not be enough for all the variables

about local variables: you could the iy register (for variables) so when ever theres a context switch you set iy to the start of the threads variables
and make all the system resources on a fixed address but the user has to mannually load the flags address in ix or so

That way you have 16Kb-(size of sys vars) space to allocate local vars AND have the 2 RAM pages for other purposes (btw weren't there 4 (or 8 ) RAM pages on 83+SE, 84+ and 84+SE?)

Anyway I think an OS only has to include the basic routines (file handling, multitasking, and so) and the GUI, CLI or Explorer is just an application that runs when the system 'starts' up, meaning that there's no difference between any other apps

Thinking of apps, If you want everything to directly run from the flash means that every program has to be (minimum) 16Kb in size, but with ram programs you can store them with their real size (though they would take a whole 16Kb RAM page to run)
Then again, you could reserve a page to run multiple small tasks (wich don't use absolute addresses and if they need to call something you could do something similar like the B_CALL:

Code: Select all

small_task:
; call one of it's sub routines:
-  call fixed_address     ; or use a rst
   .dw address_of_routine_to_call_offsetted_from_small_task
   jr {-}

fixed_address:
   pop hl
   ld e, (hl)
   inc hl
   ld d, (hl)
   inc hl
   push hl
; You just need a way to get the address of the task
   add hl, de
   jp (hl)
; To return from the subroutine just do ret since the return address is on the stack
; Downside: DE and HL are destroyed

...requiring that you have some useful skill or knowledge to add...

I hope these ideas help


EDIT:

@driesguldolf: just start at 0 instead of (what is that weird address anyway?)

?

[benryves]

Hey Ben, good to ehm... "see" you again How are things going?

Good to see you working on this project.

Could someone please point me to some kind of reference that would explain (or make it obvious) to me what all the different .org's and port read/writes in the (let's call it) "boot sector" are good for?

Unfortunately, the initial port read/write black magic that occurs on boot is calculator-specific (and should be on WikiTI). The Z80 doesn't need any special initialisation. The only magic addresses to be aware of are those related to interrupts, documented well in the user manual.

That reminds me of a problem my ideas don't yet address; absolute jumps in a relative context... I would prefer to execute programs directly from flash ("the file system") to keep the RAM as empty as possible, let them allocate some memory through the kernel, and only have to swap the stack and the registers on a context switch. But that would require us to convince sdcc to keep from using call and jp, or somehow magically work around it...

You could change absolute jumps into some sort of instruction that calls a function of the OS, which adds the requested offset to the offset to the start of the program in memory and overwrites the original instruction so that later jumps or calls are faster (they now know the "real" address so don't have to call the OS function - if in Flash that part fails, but doesn't really matter). The problem then is absolute memory addressing for data within the program, rather than jumps, but you could create formatted binaries with a resources chunk to avoid this issue (such a resources chunk could also help split the code from the data and be used to help avoid the >8K limit problem).

You talk about a file-system; this was the thing that put me off such an OS project. Are you going to make such a thing modular (maybe have different drivers, so that you could implement the RAM file system and ROM file system differently, but have a standardised API for accessing them?) Such a thing could then be extended to a USB driver (84 series) or a VDrive2 driver, for example. I'd love to see some sort of user-extendable driver subsystem in the OS, pushing all hardware access through it.

[King Harold]

If someone makes that work, I'd dearly love to see the code for it
It makes me wonder why there isn't an "universally best file-system for any and every device", why can't something be optimal for all cases?
Btw, how would you handle standardized writing? Writing to flash is somewhat.. complicated..


edit:

?

Operating systems start at/(at least)include $0000 on page 0, so just .org 0, and don't link, just use raw output.
That reminds be, I would like to be able to output to a raw (not Intel-hex) without overwriting at $4000 as soon as I have more than 2 pages.. How could I do that?

[benryves]

It makes me wonder why there isn't an "universally best file-system for any and every device", why can't something be optimal for all cases?
Btw, how would you handle standardized writing? Writing to flash is somewhat.. complicated..

I think you answered your own question. A file system has to work well with the constraints of the physical medium. With the file system in RAM you could probably get away with something simple and space-efficient as it's very easy (and fast) to rearrange memory on the fly. With Flash ROM a rather different sort of file system would need to be written.

Btw, how would you handle standardized writing? Writing to flash is somewhat.. complicated..

If the OS provided API calls for fopen(), fread(), fwrite() and fclose()-style statements that were redirected to the drivers, that might work.

[King Harold]

Ah I see..
I wonder about fwrite() though, what should the driver do when you're trying to do that with an archived file?
Buffer the entire file in RAM and write back when closed?

[Timendus]

But Tim, what I meant by making the thread switcher "callable" is that you could call it as though it were a "sleep(0)" call ensuring that other threads would get a chance to run - if there any (if not, the CPU time taken up doesn't bother any thread) and resetting the counter thingy used for priorities or whatever (assuming you have such a thing)

I don't really see a use for priorities here, so I'd rather keep away from them if possible And if there's just one process just handing control back in every time it gets CPU control, perhaps we could do something like a "soft APD" where the OS goes into low power consumption mode, while still calling the thread(s) once in a while. That way it could "revive" the calculator when it receives incoming data or whatnot

Code: Select all

.org 0
jp startup
.org $53  ;bootcode seems to check for this
jp startup
.db $5A,$A5
startup:
;you could initialize the hardware..
;but why would you if you're not going to use it..
;no code here - which means $FF opcodes, which is RST $38
;what would be the interrupt routine will keep calling itself

Shouldn't you also initialize some code at $0038 then? Or you could keep it in im 0, of course.

Isn't that a good thing? There'd be less work to do, development would go by faster, and there'd be something for everyone to play with sooner.

The development IS most of the playing Anyway, the main reason is that I don't expect him to want to help another project when he's working on his own, and we can't really join his if we want to code in C.

The .orgs are to support the use of rst ##h calls, you can put some small very usefull routines there

Yes, I saw Jim do that, but what the hell is the use? Why not just use call? What does rst do really? Being a Ti-83 guy myself I've never really seen the point in bcall

Thinking of apps, If you want everything to directly run from the flash means that every program has to be (minimum) 16Kb in size

Is that so? I don't think that's necessarily true. I know you can only reset the flash one page at a time, but I think some smart flash file system should be able to abstract that from the rest of the system, and allow for storing as many files as will fit in a flash page. In other words:

I wonder about fwrite() though, what should the driver do when you're trying to do that with an archived file?
Buffer the entire file in RAM and write back when closed?

Yes, something like that

@Ben: I'll see if I can find the time to read up on the boot process some time soon, thanks for the pointers.

On the subject of using the flash as a file system and the RAM for variables and whatnot, I guess I should copy paste what I wrote last night so you get an idea of what I want.

Memory usage
I want to use the flash as file storage and keep the entire RAM free for programs to use, with the kernel giving out pieces of RAM to programs that do a malloc (NO SWAPPING to flash though, or we'll wear the flash out real soon - if we're out of memory we're out of memory). I think we could perhaps even do with the overhead of letting the kernel access the RAM instead of the program, to ensure that threads don't go overwriting each other's memory (we should at least somehow ensure that the kernel threads are safe, preferably by keeping them in flash and not requiring any RAM, just using local variables on the stack and in the registers). Accessing the file system (the flash memory) should be the territory of the kernel.
Huge amounts of "saferams" combined with programming in C instead of tedious assembly, should give programmers incredible flexibility in what they can write. Also, in the more distant future, it could allow for "Ti-OS simulation" by allocating all the saferam areas and putting function hooks in the right places before running assembly programs that were originally intended for the original OS. Such a thing could greatly increase it's popularity.

You talk about a file-system; this was the thing that put me off such an OS project. Are you going to make such a thing modular

Yeah, me too. But I've found a guy who's already done something similar I think. Should contact him soon I'd prefer a nicely modular file system that, as you say, can be used for USB storage devices, network mounts and whatnot, but let's start with something working

Okay, I'm off. I'll be back after the weekend Nice to see some discussion on the right topics this time! Says a few good things about the level of maturity of Maxcoderz compared to UTI where this sprouted last time

[benryves]

Yes, I saw Jim do that, but what the hell is the use? Why not just use call? What does rst do really? Being a Ti-83 guy myself I've never really seen the point in bcall

rst is smaller and faster than a call (it's a single byte). Typically you'd put a simple function that is called a lot there, hence the TIOS using them for things like bcalls or copying nine bytes of data to OP1.

@Ben: I'll see if I can find the time to read up on the boot process some time soon, thanks for the pointers.

Sorry I can't be much use, I found the whole boot-up procedure rather confusing (I never got the TIOS booting in my emulator).

Memory usage
I want to use the flash as file storage and keep the entire RAM free for programs to use, with the kernel giving out pieces of RAM to programs that do a malloc (NO SWAPPING to flash though, or we'll wear the flash out real soon - if we're out of memory we're out of memory).
...

Sounds good to me.

I'd prefer a nicely modular file system that, as you say, can be used for USB storage devices, network mounts and whatnot, but let's start with something working

Aye, but as long as you keep modularity in mind so it can be swapped in at a later date without breaking everything.

[King Harold]

Is not the point of BCALL's that you can have a load of routines on pages other than 0? And, although less important, BCALL's don't have to change address when you remove a few bugs or optimize something.
On the other hand, that is both possible with CALL's (although it'd be a mess imo, unless every routine is on page 0)
RST routines, well, they just save 2 bytes every time they are called.. Personally I'd put a few routines there that are needed fairly often, but it's not going to matter a lot
How do you plan to keep track of how much RAM has been malloced and where?

[calc84maniac]

Thinking of apps, If you want everything to directly run from the flash means that every program has to be (minimum) 16Kb in size

Is that so? I don't think that's necessarily true. I know you can only reset the flash one page at a time, but I think some smart flash file system should be able to abstract that from the rest of the system, and allow for storing as many files as will fit in a flash page. In other words:

Technically, you can only reset the flash a sector (4 pages) at a time, which means that you can have programs up to 64KB without sector overlapping. (Why don't we want sector overlapping? Because Garbage Collecting would be a huge nightmare.)

[CoBB]

Protothreads look like fun, but I'd rather have proper multithreading, combined with threads being able to hand the processor back in.

Think about the consequences. I guess that's exactly what Dunkels did before coming up with protothreads.

The problem then is absolute memory addressing for data within the program, rather than jumps, but you could create formatted binaries with a resources chunk to avoid this issue

Other than dragging along relocation tables (ugh!) I don't really see another way either. I do wonder though how the C compiler can be convinced to use an extra indirection all the time though... Maybe all data should be accessed through the filesystem and provide an API to handle what would look like memory mapped files.

(such a resources chunk could also help split the code from the data and be used to help avoid the >8K limit problem).

That's not a hardware limit, it's imposed by the TIOS. A custom OS can set execution protection as it pleases.

Anyway, I have very strong doubts whether supporting C on the user end is a really good idea. It is an extreme amount of hassle if you want to make it work with multitasking and all that. I'd rather propose the following: provide support for a managed language and assembly. However, I'm not thinking of an interpreted language like TI-BASIC, rather something that's compiled to a virtual machine on a computer. I do mean a proper structured language here, not the abomination TI-BASIC is. Managed code would make multitasking and sensible memory/peripheral management much more feasible (it could provide keyboard or link events for instance as well as synchronisation mechanisms). Assembly code could monopolise the CPU just like so far, but the OS would still provide a sensible API to access resources and play nice with others. Also, calling assembly from managed code and also the other way around should be made very easy.

[calc84maniac]

(such a resources chunk could also help split the code from the data and be used to help avoid the >8K limit problem).

That's not a hardware limit, it's imposed by the TIOS. A custom OS can set execution protection as it pleases.

No, it is a hardware limit. RAM page 0 does an rst 00h (or maybe jp $0000) if PC is on it. In fact, this happens for any even-numbered RAM page. It could be easy to avoid if we make this 83+SE/84+/84+SE only, as we can swap in an odd-numbered RAM page to $C000 to $FFFF in that case.

[benryves]

I'd be very interested to see how a proper managed language + VM solution turns out on the calc. Depending on how it is implemented it could potentially be used to run Vera programs on the regular TIOS. It's something I've been considering writing myself recently, having done some work with the QuakeC VM.

As far as performance goes, if you could write native libraries that were available from the VM you should still get decent performance with easy(ish) development.

[CoBB]

No, it is a hardware limit. RAM page 0 does an rst 00h (or maybe jp $0000) if PC is on it. In fact, this happens for any even-numbered RAM page.

On the standard 83+, execution protection can be manipulated from software through port 0x16, at least if you’re the one writing the OS. In fact, a bit of code is executed on page 0 during the boot process.