Hello from UK! and presenting dflat system
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Hello from UK!
Yeah it sure seems that Oric is getting a lot more attention now than ever ..
Re: Hello from UK!
Indeed. Fascinating times
Re: Hello from UK!
Hi 6502Nerd,
On second thougths, while it is of course nice to design a custom ROM for dflat, it would also be nice to allow the editor+tokenizer+runtime lib (ROM at present) to be loaded into RAM (like Forth implementations for the Oric) even though it would drastically reduce available space to programs of course... I think most people would be interested in this rather than having to replace their Oric ROM with a custom EPROM... And maybe there might be a way to leverage some of the existing ROM routines so they could be reused in dflat, thus reducing the size of the runtime?
Anyway, as to integrating it into the OSDK I must point out I'm neither the designer nor the maintainer of this toolkit, and IMHO it probably would only make sense to add dflat tokenizer and interpreter support if these could be packaged to be loaded into RAM... But of course you're entirely free to do what you want, especially since you're also designing dflat tor un on your custom SBC!
In any case, I hope you'll share more details about the parts of dflat (language itself, tokenizer, interpreter and ROM / runtime lib) as you progress,
And it will be great of course if you intend to publish all or part of dflat to GitHub
On second thougths, while it is of course nice to design a custom ROM for dflat, it would also be nice to allow the editor+tokenizer+runtime lib (ROM at present) to be loaded into RAM (like Forth implementations for the Oric) even though it would drastically reduce available space to programs of course... I think most people would be interested in this rather than having to replace their Oric ROM with a custom EPROM... And maybe there might be a way to leverage some of the existing ROM routines so they could be reused in dflat, thus reducing the size of the runtime?
Oh yes, I got a little carried out and forgot dflat was interpreted and used a custom ROM So integrating it to OSDK is not really possible as it stands.6502Nerd wrote: ↑Sun Oct 11, 2020 10:34 pm What a great idea retoric for the possibility for dlfat to be part of OSDK, that would be an amazing thing to get involved with.
Of course as dflat is a tokenising interpreter with an line-line assembler rather than compiler, I am sure that it will be much slower than C !!
I have read about OSDK but not used it so would need assistance to implement your idea.
Anyway, as to integrating it into the OSDK I must point out I'm neither the designer nor the maintainer of this toolkit, and IMHO it probably would only make sense to add dflat tokenizer and interpreter support if these could be packaged to be loaded into RAM... But of course you're entirely free to do what you want, especially since you're also designing dflat tor un on your custom SBC!
In any case, I hope you'll share more details about the parts of dflat (language itself, tokenizer, interpreter and ROM / runtime lib) as you progress,
And it will be great of course if you intend to publish all or part of dflat to GitHub
- 6502Nerd
- Pilot Officer
- Posts: 111
- Joined: Thu Oct 08, 2020 9:48 pm
- Location: Leicestershire, UK
- Contact:
Re: Hello from UK!
Thank you! Yes there is a lot of life in the Oric as long as software and electronics folk keep it going. I would not believe in 1983 that I would be spending any time making something for the Oric!
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: Hello from UK!
Was exactly my first thought (but did not want to be that party pooper ): very nice, but how will I get that ROM on my original Oric hardware as I am definately not going to solder and replace my ROM in that thing.... (have no hardware skills whatsoever more advanced that screwing the case loose and connecting basic stuff that does not need soldering).
But that got me thinking: as far as I understand, the actual ROM that I am using on my machine in practice, is not the ROM inside my original Atmos hardware, but the ROM present in either my Erebus or Cumana Reborn connected to the Atmos, right?
So would the ROM of the Erebus / Cumana Reborn or maybe e.g. the Twilighte board be swappable to use a Dflat ROM instead? Problem might be that it would create even more storage space issues for 6502Nerd that already present as in those cases also the DOS used in those ROMs needs to fit....
Might I even dream in someone (again, certainly not me) creating a über/final solution combining everything Cumana Reborn/Erebus/Twilighte Board has to offer in one device with swappable ROM images? I presently use such a one device to do all for my Commodore 128D (the Ultimate II+ cartridge that does full disk and tape emulation, provides network and has fully swappable ROM extension possibility), would love and instantly buy one for my Oric.
Or am I completely mistaken now on how those Oric mass storage extensions work? They basically replace the internal ROM, right? Even as far as making an Oric 1 an Atmos software wise....
Re: Hello from UK!
In the Erebus Rom, the the first and last bank memory are used for BasicRom Atmos and SdCard, it remains two banks with 16Ko each, burnable for Dflat language.
Re: Hello from UK!
Well, I guess if you have a disk drive (Cumulus, Cumana, Microdisc, Jasmin ,...) you have access to the overlay ram, so dflat should be trivial to use without any rom change by implement some "launcher file" which when loaded from disk does:
- Load "dflat.bin" somewhere in low ram
- Disable IRQ
- Make sure that the overlay ram is enabled
- Copy the bin file to c000-ffff
- Call some initialization routine there
- Profit
- Load "dflat.bin" somewhere in low ram
- Disable IRQ
- Make sure that the overlay ram is enabled
- Copy the bin file to c000-ffff
- Call some initialization routine there
- Profit
- xahmol
- Flight Lieutenant
- Posts: 437
- Joined: Sun Jun 28, 2020 7:32 pm
- Location: Utrecht, The Netherlands
- Contact:
Re: Hello from UK!
Sounds promising! So lets do it! (again, not me, sorry.....happy to be the test monkey though)
- 6502Nerd
- Pilot Officer
- Posts: 111
- Joined: Thu Oct 08, 2020 9:48 pm
- Location: Leicestershire, UK
- Contact:
Re: Hello from UK!
I'm delighted to have the inputs and ideas from you all, lots of options here to make dflat more usable for real Oric hardware.
So far I have been testing mainly using Oricutron - I simply replaced the Atmos ROM image with my custom ROM image (also, I realised I needed to clear the patch file!!). However I have also been trying it on a real Oric - I made a small breadboard circuit to connect to the expansion port which maps out the onboard ROM and maps in an EEPROM, which means I don't have to open the Oric case (also I have an additional 6522, but software does not use that)
The core of dflat including in-line assembler is probably less than 10KB and could use the BIOS of the existing ROM. On my homebrew, dflat can work over serial as it really just needs a 'put byte' and 'get byte' to interact.
However there would be a speed penalty - the Oric IRQ seems rather heavy. The ROM keyboard routines are not great either - I completely rewrote as part of the BIOS underneath dflat. As part of this, the keyboard is no longer scanned at all during IRQ (all it does now is update a few timers at 50Hz, although it also has provision for user IRQ routines to be called). On top of the IRQ load, the ROM routines for line and circle are pretty slow too, as well as all of the text plotting - all replaced by the BIOS layer in the dflat ROM.
But many possibilities here! First, I should get the project working as a replacement ROM which people can try on emu, then I am sure other options can be made
So far I have been testing mainly using Oricutron - I simply replaced the Atmos ROM image with my custom ROM image (also, I realised I needed to clear the patch file!!). However I have also been trying it on a real Oric - I made a small breadboard circuit to connect to the expansion port which maps out the onboard ROM and maps in an EEPROM, which means I don't have to open the Oric case (also I have an additional 6522, but software does not use that)
The core of dflat including in-line assembler is probably less than 10KB and could use the BIOS of the existing ROM. On my homebrew, dflat can work over serial as it really just needs a 'put byte' and 'get byte' to interact.
However there would be a speed penalty - the Oric IRQ seems rather heavy. The ROM keyboard routines are not great either - I completely rewrote as part of the BIOS underneath dflat. As part of this, the keyboard is no longer scanned at all during IRQ (all it does now is update a few timers at 50Hz, although it also has provision for user IRQ routines to be called). On top of the IRQ load, the ROM routines for line and circle are pretty slow too, as well as all of the text plotting - all replaced by the BIOS layer in the dflat ROM.
But many possibilities here! First, I should get the project working as a replacement ROM which people can try on emu, then I am sure other options can be made
Re: Hello from UK!
Nice test setup !
What is the chip you use on the bottom left above the ribbon cable (supposedly for address decoding) ?
On the subject of your "BIOS" and dflat implementation hardly fitting in 16 kB... I suppose you could consider using *two* 16 kB EPROMs with additional address decoding with maybe an I/O address in page 3 to control banking, with 'switching' logic on the PCB... This way you could easily fit the rest of your routines and maybe add DOS routines like the Sedoric DOS, or at least tape routines (easier said than done of course...) ? It then could be quite useable on an Oric if all we need is to connect some PCB with the dflat EPROMs and a ribbon cable !
Unfortunately, on the emulator (Oricutron) side of things, it might be a little complicated to implement management of multiple ROM 'banks'...
What is the chip you use on the bottom left above the ribbon cable (supposedly for address decoding) ?
On the subject of your "BIOS" and dflat implementation hardly fitting in 16 kB... I suppose you could consider using *two* 16 kB EPROMs with additional address decoding with maybe an I/O address in page 3 to control banking, with 'switching' logic on the PCB... This way you could easily fit the rest of your routines and maybe add DOS routines like the Sedoric DOS, or at least tape routines (easier said than done of course...) ? It then could be quite useable on an Oric if all we need is to connect some PCB with the dflat EPROMs and a ribbon cable !
Unfortunately, on the emulator (Oricutron) side of things, it might be a little complicated to implement management of multiple ROM 'banks'...
Re: Hello from UK!
Ah,
Just saw the answers from Kenetth and DBUg... Very good points !!!
Just saw the answers from Kenetth and DBUg... Very good points !!!
- 6502Nerd
- Pilot Officer
- Posts: 111
- Joined: Thu Oct 08, 2020 9:48 pm
- Location: Leicestershire, UK
- Contact:
Re: Hello from UK!
The chip is just a 74LS00, yes to support addressing the 6522. It's not very clever addressing though - the 6522 is at 0x380, but any 0x3xx address with bit 7 set will select this 6522.retroric wrote: ↑Mon Oct 12, 2020 6:17 pm Nice test setup !
What is the chip you use on the bottom left above the ribbon cable (supposedly for address decoding) ?
On the subject of your "BIOS" and dflat implementation hardly fitting in 16 kB... I suppose you could consider using *two* 16 kB EPROMs with additional address decoding with maybe an I/O address in page 3 to control banking, with 'switching' logic on the PCB... This way you could easily fit the rest of your routines and maybe add DOS routines like the Sedoric DOS, or at least tape routines (easier said than done of course...) ? It then could be quite useable on an Oric if all we need is to connect some PCB with the dflat EPROMs and a ribbon cable !
Unfortunately, on the emulator (Oricutron) side of things, it might be a little complicated to implement management of multiple ROM 'banks'...
The EEPROM I am using is actually a 64K one (27C512) - same as I use on my homebrew. On that machine, I use port pins of a 6522 to control the A14 and A15 pins of the 27C512, so I have 4 banks to pick from... and as I had the space, this ROM has dflat plus serial device support, and also (which I am very pleased with) a basic FAT16 filesystem on top of the BIOS driving an SD Card
As you say, will be difficult to test this on emu, but the expansion breadboard could do it with the extra 6522 I have there. But I think I will keep it to 16KB to allow anyone to try it on emu.
I am very appreciative of the interest and ideas of this community - I wish had joined many years ago
Re: dflat
Dbug's suggestion is sound. It would be the best way to test, as the ROM contents would be in a file in the disk and would be loaded into overlay RAM. Exactly as the SEDORIC tool to put Oric-1 or Oric Atmos ROM in overlay RAM.
EDIT: Moved the topic from General
EDIT: Moved the topic from General
- coco.oric
- Squad Leader
- Posts: 720
- Joined: Tue Aug 11, 2009 9:50 am
- Location: North of France
- Contact:
Re: Hello from UK! and presenting dflat system
Welcome 6502nerd.
@retroric
Anyway, i've enough hardware to keep one UC for each hardware configuration
(and if anything goes well, i'll got an oric-1 on next tuesday)
@retroric
Not 100% : i want to keep my oric on original hardware ; a good atmos with tzx hardware instead of tapes, and a cumulus / a cumana reborn instead of dsk files.I think most people would be interested in this rather than having to replace their Oric ROM with a custom EPROM
Anyway, i've enough hardware to keep one UC for each hardware configuration
(and if anything goes well, i'll got an oric-1 on next tuesday)
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
Historic owner of Oric, Apple II, Atari ST, Amiga