Towards an onboard Oric Assembler/Editor Development environment

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.
User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

From this thread discussing the virtues of various cross-assemblers ("XA or CA65") , was this slight diversion (thus I create a new thread) on what it would take to build an onboard assembler and editor system for the Oric:
Dbug wrote: Sat Jul 30, 2022 1:27 pm
ibisum wrote: Sat Jul 30, 2022 12:12 pm As a non-guru, devoted Oric lover, what I want: an onboard editor and assembler that is worth the effort to set up and learn. Cross-compiling is productive - compiling/assembling/debugging onboard, just much more fun.

I've been trying to get a MONASM.DSK built for the last few weeks in my (very few) Oric sessions, but haven't had much luck. But I continue to yearn for an Otic-onboard set of tools that would allow full assembly-based development with just the machine itself. I've thoroughly enjoyed the options on Amstrad (MAXAM, CHAMP, etc.) and would think we Oric people deserve something similar, at least ..
Imo, a reasonable way of doing that would be to use a cartridge system, like the ones used on the C64, because else you are losing quite a lot of memory, since you basically need to store the entire assembler/monitor/editor system, but also the source code of the program you are assembling.

With a cartridge which would have both 16K of ROM as well as the few components required to access the overlay memory, you could have a system that allows developing 48K Oric software by having the entire editor/assembler/disassembler in the ROM cartridge, but also having up to 16KB of source code inside the overlay memory so no main memory wasted by the source code.

So .. I would imagine that this is something for Orix/Twilighte-Board/Sittler hackers to consider implementing (if iss&Jede&co haven't already done so) in the new memory layout.

Or is there some way to implement a "ROM cartridge mode" for Cumulus/Cumana Reborn/TxDuino/Erebus?

Lets discuss the means/methods by which we can attain a functional, decent development environment for the Oric-1/Atmos/New Oric platforms, which allows us to write assembly directly for the machine, and so on.
Last edited by ibisum on Sun Jul 31, 2022 3:08 pm, edited 1 time in total.
User avatar
Dbug
Site Admin
Posts: 4084
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Dbug »

Well, not sure that could be done out of the box with any of the existing hardware, but basically imagine an extension of what the Oric Microdisc typically does.

I did explain in some detail how the upper part of the memory works in the following article, but the crux of the thing is in the picture.
image_2022-07-31_155819334.png
Basically we can have multiple ROM already in the system, in the case of the Microdisc (or Cumulus/Cumana) basically a combination of ROMDIS and MAP signal allows to choose between the microdisc boot rom, internal basic rom, or overlay ram.

Not all the bits if the register $314 are used, so technically some could be used for other things like "ROM number", and instead of just a simple 8KB ROM like on the Microdisc, you could cycle between multiple 8 or 16KB ROM.

Now of course the tricky part as usual is that you can't really have a DOS and use the overlay ram to also contain data, so as you said, the ideal setup would be the Orix/Twilighte card, but I think Jede idea was to use it to fastly upload programs cross assembled from a PC.

I guess an alternative system could be to connect something to the Oric, a bit like what the 8bit hub is doing with the parallel port, inside he has a ESP32 microcontroller which has enough embedded storage to have a firmware and do fancy things, so technically you could do something as minimal as just having a read/load kernel that just read and write bytes to the external controller, and use it to do the compiling for you, which means you could still exploit whatever Cumulus, Cumana, Microdisc or Erebus you have, and lose almost no memory at all.

The question is ultimately: What do we call "native Oric development", because even Xenon 1 was not programmed on an Oric (it was on a BBC) and neither was The Hobbit, neither are PlayStation, Xbox, Saturn or NES games done on the real hardware, all these are using cross compiling :)
User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

The question is ultimately: What do we call "native Oric development"
Well, I think we all want to see the Oric persist as a platform for many years more to come, and that is not always going to be supported by cross-compiling, although it mostly *is*. The natural progression for the Oric as a platform is to see its ecosystem gain traction - and certainly, a single-image/file development environment which you run ON the machine itself (or a new generation, or an emulator..) is a good way to gain that traction.

Not everyone has the temerity, or indeed desire, to commit a PC to the task of cross-compiling - part of the fun of retro- computing is making the old computers do new and amazing things. The Oric deserves onboard tooling that only does things for the Oric, and nothing but the Oric. /zealotrymode

It can be argued that its not really a computing platform if you need another computing platform to do anything useful with it - but such a position, especially in the zealotry end of the spectrum, simply means no more Erebus or Cumulus or Cumana Reborn or any of that, because those are in fact 'cross-platform super computers being used for the task of feeding a 1mhz machine with less memory than your average L1 cache'.

The answer to the question of 'what do we call native Oric development' is simply this: is the tool something you run ON the Oric, to build software FOR the Oric? We do indeed have a lot of that tooling - far and wide, the open/public tooling (Twilight's' repo's/DBugs repo's/etc.) as well as the custom stuff we all have tucked away somewhere.

The goal is, lets build something any Oric user can download, and use to build cool new software for the Oric, with the Oric.
User avatar
Dbug
Site Admin
Posts: 4084
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Dbug »

Then I ask the second question, should it run on a pure tape system, or would a floppy disk drive system be an acceptable base level?

Because basically for tape systems, I doubt it's possible to do significantly better than any of the existing assembler/disassembler which were published in the 80ies.

With a disk system on the other hand, you are not obliged to have all the source code in memory, you could just have the visible part in memory, and have the assembler dynamically loaded when required, have the debugger loaded when required, and with a custom loader (think "Floppy Builder" based, not "Sedoric" based) you can actually use most of the overlay ram - but that means your development environment has a custom file system which is not normally readable, but of course that does not mean it's not possible to make a DOS compatible tool that can read/write to the specific format.

Basically for this type of project, you need to define constraints and guidelines, that's the only way to make something even remotely usable.
User avatar
Dbug
Site Admin
Posts: 4084
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Dbug »

Found a relevant post on Twitter with something similar to what you want on BBC micro:

User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

Then I ask the second question, should it run on a pure tape system, or would a floppy disk drive system be an acceptable base level?
Its just my opinion, but at some point it will be time to let go of tape support and make disk usage a standard for these kinds of tools. Of course, we should be able to produce tape images with these tools - but the hosting of the tools themselves might just as well be disk based. This way we can have 'near infinite' memory for the tools to use, I guess.

For some reason, I've been unable to create a .DSK image with MONASM in it .. but I'm going to poke at this a little more this week .. it would at least a first step.

>Galaforce being compiled on BBC Micro

Wow, this is exactly where I think we should try to go with an Oric tooling framework. Delightful to see a good example.
User avatar
Dbug
Site Admin
Posts: 4084
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Dbug »

A possible approach would be to write a tiny program (kind of a micro shell) to allow switching between multiple modes:
- Text editing
- Assembling
- Debugging
- Running

If that was made as dynamically loadable modules that could also contain dedicated "tool" modules for example to edit graphics, make sound, create tables of values (line sinus curves, sprite movements, etc...), database of items, strings of text, etc...

Each of these could rely on a small persistant kernel in charge of doing I/O, like being able to read/write bunch of bytes from files, so you would not have to have the entire source code in memory, neither would have to get the entire generated binary.

That's obviously non trivial to make :)
User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

That's obviously non trivial to make :)
I'm under no delusion that any of this is trivial, or else it would have been done before many times over .. for now I've settled on trying to get MONASM and a few other handy utilities together in a loosely collected "DEVUTIL.DSK" image, for further experimentation.

The goal is to have enough tooling onboard to write a bit of assembly, with the Oric itself. MONASM allows for that .. if I can just find a better BASIC editor, it might suffice for a lot of hacking sessions...
small persistant kernel in charge of doing I/O, like being able to read/write bunch of bytes from files,
I mean, would it not be feasible to use SEDORIC(*) to get access to some general-purpose file I/o routines, and then - as you say, get a loader/unloader menu rigged up to load disk functions when needed ..

(* - I don't remember if there is a disassembly, akin to the Atmos ROM, around somewhere ..?)


EDIT: This 65C02 conditional assembler seems pretty decent, but I have no clue how to use it .. anyone seen some docs, or got the druthers to poke at the .DSK and figure it out?

https://www.oric.org/software/65c02_con ... r-698.html
User avatar
Dbug
Site Admin
Posts: 4084
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Dbug »

ibisum wrote: Wed Aug 03, 2022 8:54 pm I mean, would it not be feasible to use SEDORIC(*) to get access to some general-purpose file I/o routines, and then - as you say, get a loader/unloader menu rigged up to load disk functions when needed ..
We were looking at that with Xamol for the Petscii editor tool the other day, Sedoric is not modular to the point you can just use some parts of it without requiring most of the overlay memory to be used.

As long as there is a way to import/export from something standard without too much struggle, then it's not much a hassle to have a custom operating system and file format optimized for the development.

If you want your development environment to run from a standard OS floppy, it means you need too the stuff required to parse directories, list of free sectors, etc... and this stuff takes a lot of room by itself, plus all the code required to manipulate it.
Jonh
Officer Cadet
Posts: 46
Joined: Tue Jun 01, 2021 4:07 pm
Location: Cambridge, UK

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Jonh »

Ibisum wrote
EDIT: This 65C02 conditional assembler seems pretty decent, but I have no clue how to use it .. anyone seen some docs...

I have found the manual, posted (twice!) to Stuff on https://www.oric.org/software/65c02_con ... r-698.html
User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

Thanks for that, JonH - I often get tripped up by the "Stuff" section not being visible when I'm not logged in on oric.org, so I completely overlooked that .. off to do a bit of study and some workshop'ing to see how useful this assembler is, will report back soon ..
Jonh
Officer Cadet
Posts: 46
Joined: Tue Jun 01, 2021 4:07 pm
Location: Cambridge, UK

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by Jonh »

No, you didn't overlook it, it wasn't there when you posted the request for docs. I found an original manual in my own 'Stuff'' in the loft, scanned and posted it yesterday afternoon :) Unread for 30+ years!
User avatar
ibisum
Wing Commander
Posts: 1535
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Towards an onboard Oric Assembler/Editor Development environment

Post by ibisum »

Ah, amazing! Well, thanks for making that effort, it has definitely enhanced the landscape for onboard assembly.

I've got a large Oric session planned in my lab this weekend, I will dig through all of this and report back.
Post Reply