An Oric "TOOLS.DSK" archive?
- ibisum
- Wing Commander
- Posts: 1646
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
An Oric "TOOLS.DSK" archive?
I think it would be really nice to have a big collection of Oric/Atmos tools/utilities on a .DSK that support 'onboard' coding.
I never had much experience with the Atmos assembler, I remember there was some sort of 'new EDIT' mode that allowed direct entry of asm, or am I just daydreaming .. ?
Well if I have a point, it is that with the possibility of reviving the machines, and keeping them useful and active, wouldn't it be great to have vi and so on, ported? An onboard C compiler with full DSK support?
I daydream of this, anyway, I believe the machines in my control will one day be 'really' complete vis-a-vis onboard-compiler nature ..
Whats in, or what you gonna put in your "C-UTIL", folks?
I never had much experience with the Atmos assembler, I remember there was some sort of 'new EDIT' mode that allowed direct entry of asm, or am I just daydreaming .. ?
Well if I have a point, it is that with the possibility of reviving the machines, and keeping them useful and active, wouldn't it be great to have vi and so on, ported? An onboard C compiler with full DSK support?
I daydream of this, anyway, I believe the machines in my control will one day be 'really' complete vis-a-vis onboard-compiler nature ..
Whats in, or what you gonna put in your "C-UTIL", folks?
Well, a native C compiler is doable if you are willing to spend hours waiting for a small program to compile (using a lot of disk swapping).
Assembler, that's easier.
Technically, what you would really want to do, is to have a assembler/disassembler that fits entirely in a 16k ROM module, and then have some way to switch between the "assembler ROM" and the normal ROM, effectively as some kind of cartridge system (like the Action Replay thingies they have on the Commodore 64).
The reason you don't really want to have that loaded from disk, is that when you assemble, you need to have in memory at the same time: the program to assemble (the one you are editing), the assembler software itself, the intermediate data, and the final executable, so every small amount of memory you can save can help building bigger programs.
You can of course have everything stored on disk, but then you are going to spend more time doing I/O than actually compiling the program
Now, if your target system is Cumulus, it's probably possible to do something smart, because after all the "microdisc rom" and the "overlay signal" is entirely handled by the Cumulus board, and you can change that by changing the firmware implementation.
Another advantage of the ROM based system, is that you can have a "post mortem boot rom" feature, that allows you to visualize/disassemble the content of the memory when your program crash and you had to reboot: No clearing of the memory, and an optimized debugger that does not overwrite anything in your program's memory.
Hope this makes sense
Assembler, that's easier.
Technically, what you would really want to do, is to have a assembler/disassembler that fits entirely in a 16k ROM module, and then have some way to switch between the "assembler ROM" and the normal ROM, effectively as some kind of cartridge system (like the Action Replay thingies they have on the Commodore 64).
The reason you don't really want to have that loaded from disk, is that when you assemble, you need to have in memory at the same time: the program to assemble (the one you are editing), the assembler software itself, the intermediate data, and the final executable, so every small amount of memory you can save can help building bigger programs.
You can of course have everything stored on disk, but then you are going to spend more time doing I/O than actually compiling the program
Now, if your target system is Cumulus, it's probably possible to do something smart, because after all the "microdisc rom" and the "overlay signal" is entirely handled by the Cumulus board, and you can change that by changing the firmware implementation.
Another advantage of the ROM based system, is that you can have a "post mortem boot rom" feature, that allows you to visualize/disassemble the content of the memory when your program crash and you had to reboot: No clearing of the memory, and an optimized debugger that does not overwrite anything in your program's memory.
Hope this makes sense
A C compiler with the capabilities of a good cross compiler would probably be larger than ORIC RAM. You'd need to split it up into sections and generate intermediate files between compilation stages.
This method was used on several compilers back in the day and they were much more limited than today's compilers.
This method was used on several compilers back in the day and they were much more limited than today's compilers.
- ibisum
- Wing Commander
- Posts: 1646
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Well, I wonder what it'd be like to have a more advanced language on the Oric than BASIC, anyway .. or at least have an Assembler editor/IDE that helps the process of weaning oneself off Oric BASIC ..
But, put the compilers aside, and lets talk about other tools - what other tools are out there that are essential to the Oric onboard programming experience? I'm talking about the things like the Assembler-BASIC, BasicHELPER/BasicAdd utilities from this page:
http://hirudov.com/oric/
.. I remember, way back in the day, that I had a "UTILS" tape that had all sorts of collected snippets from the Oric magazine scene, thinks like the "OLD" command (which recovered code lost after a "NEW" statement), "AUTO" (for renumbering BASIC input automatically) and so on .. these utils are now lost to the ages, but I wonder what you guys remember from your days as being useful onboard utils/tools?
The reason I'm asking this, is of course because I'm trying to assemble the *ultimate* utils disk for use with the Cumulus hardware ..
But, put the compilers aside, and lets talk about other tools - what other tools are out there that are essential to the Oric onboard programming experience? I'm talking about the things like the Assembler-BASIC, BasicHELPER/BasicAdd utilities from this page:
http://hirudov.com/oric/
.. I remember, way back in the day, that I had a "UTILS" tape that had all sorts of collected snippets from the Oric magazine scene, thinks like the "OLD" command (which recovered code lost after a "NEW" statement), "AUTO" (for renumbering BASIC input automatically) and so on .. these utils are now lost to the ages, but I wonder what you guys remember from your days as being useful onboard utils/tools?
The reason I'm asking this, is of course because I'm trying to assemble the *ultimate* utils disk for use with the Cumulus hardware ..
- barnsey123
- Flight Lieutenant
- Posts: 379
- Joined: Fri Mar 18, 2011 10:04 am
- Location: Birmingham
FORTH
@ibisium Today, the Forth language can be used to program devices such as the Arduino/Gameduino connected to a PC via USB.
I haven't tried it myself but it would be a useful thing to include. It's downloadable from oric.org. Now, if only some bright spark could invent a USB interface for Oric...
Apparently - and I'm no expert - Forth is a useful language for AI purposes. I haven't tried it out myself though but it's on my roadmap.
I spotted the CharSet editor on the Hirudov site you mentioned (I was going to write one so that'll save me some leg work! Probably will need amending for a disk-based environment and include language options)
gotta go
I haven't tried it myself but it would be a useful thing to include. It's downloadable from oric.org. Now, if only some bright spark could invent a USB interface for Oric...
Apparently - and I'm no expert - Forth is a useful language for AI purposes. I haven't tried it out myself though but it's on my roadmap.
I spotted the CharSet editor on the Hirudov site you mentioned (I was going to write one so that'll save me some leg work! Probably will need amending for a disk-based environment and include language options)
gotta go
LUA is slow on powerful machines - except if you use the JIT compiler -, the reason is mostly the syntax that uses dictionaries and loose typing.
Imo, you would get all the inconvenient of C (complex syntax) and of the BASIC (horrible runtime performance).
You are better trying to design your own language, if you want to get something usable
Imo, you would get all the inconvenient of C (complex syntax) and of the BASIC (horrible runtime performance).
You are better trying to design your own language, if you want to get something usable
Something which should be doable is to design a set of routines for doing fast display of graphics, double buffering, sprite, decompression of data, copies of memory bloc, shifting of bitmap, scrolling, etc... possibly the same for sound (native support for playing samples and sound effects), tape and disk I/O and then provide an easy way to access that from either C, Assembler or BASIC.
The problem is not really that the BASIC suck, or that C is not fast enough, it's mostly that the core things should be done in a high performance language, not in BASIC.
If you get this set of core libraries, it really makes it less important which language you are using
The problem is not really that the BASIC suck, or that C is not fast enough, it's mostly that the core things should be done in a high performance language, not in BASIC.
If you get this set of core libraries, it really makes it less important which language you are using
What you will need first, is a decent set of disk I/O routines, because there is no way you can have the loaded source file and the built data in memory at the same time as the assembler.
This means you will have to do a multi-pass disk based assembler.
That's of course doable, was done on older machines, but the efficiency of the result will totally be related to how efficient your loading/saving system is
Actually, if you wanted to have something like a real autonomous Oric system, thinks like GeOS and Contiki rely on the ability to dynamically load and save parts of memory, some kind of "virtual memory" management.
So probably you should start by that, and for example implement a kind of "large text file viewer", which allowed you to show on the Oric a text file that is larger than the Oric memory itself, that would be a good start.
If you can do that, then you can reuse this for things like the assembler or compiler.
This means you will have to do a multi-pass disk based assembler.
That's of course doable, was done on older machines, but the efficiency of the result will totally be related to how efficient your loading/saving system is
Actually, if you wanted to have something like a real autonomous Oric system, thinks like GeOS and Contiki rely on the ability to dynamically load and save parts of memory, some kind of "virtual memory" management.
So probably you should start by that, and for example implement a kind of "large text file viewer", which allowed you to show on the Oric a text file that is larger than the Oric memory itself, that would be a good start.
If you can do that, then you can reuse this for things like the assembler or compiler.