An Oric "TOOLS.DSK" archive?

This is the best place to discuss about the various Oric operating systems like Sedoric, Randos, FT-Dos, and others.
Post Reply
User avatar
ibisum
Squad Leader
Posts: 872
Joined: Fri Apr 03, 2009 8:56 am

An Oric "TOOLS.DSK" archive?

Post by ibisum » Thu Apr 28, 2011 5:15 pm

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? :)

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Sat Apr 30, 2011 11:54 am

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 :)

JamesD
Flight Lieutenant
Posts: 352
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD » Tue May 03, 2011 4:17 am

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.

User avatar
ibisum
Squad Leader
Posts: 872
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Tue May 03, 2011 9:20 am

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 .. ;)

User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

FORTH

Post by barnsey123 » Wed May 04, 2011 9:07 am

@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

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Wed May 04, 2011 7:08 pm

Forth indeed is a good candidate for developing natively on the Oric, it's faster than Basic, does not require as much complex parsing as the C, and as far as I can tell it has pretty good performance.

User avatar
ibisum
Squad Leader
Posts: 872
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Fri May 06, 2011 8:11 pm

Actually .. I wonder about LUA.. ?

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Fri May 06, 2011 8:19 pm

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 :)

User avatar
ibisum
Squad Leader
Posts: 872
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Sun May 08, 2011 11:20 am

Just putting my thoughts out there .. I'd really like to have a powerful onboard language to replace BASIC, but I guess I should think, first, about getting an editor and onboard assembler and see where that leads ..

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Sun May 08, 2011 11:42 am

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 :)

User avatar
ibisum
Squad Leader
Posts: 872
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Sun May 08, 2011 1:04 pm

Thats right, but what I envision, one day, is having the sources to some of the awesome recent releases *on* the Oric/Atmos, and being able to build these games with the Oric itself. I.e. a total removal of the cross-compiling situation.

I think an assembler is needed first ..

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Sun May 08, 2011 1:13 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests