Raven. A homemade Atari-like computer

Blogs & guides and tales of woo by forum members.
Oldskool
Posts: 71
Joined: Mon Jun 29, 2020 12:23 pm

Re: Raven. A homemade Atari-like computer

Post by Oldskool »

Just checked. My Amiga 4k with graphics card gets about 9-10 fps @50 mhz. Raven looks way faster but thats probably at 100?
User avatar
agranlund
Posts: 874
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Raven. A homemade Atari-like computer

Post by agranlund »

I love having those ISA slots! Beautiful Adlib :)
It's just a quick test and the tempo is a bit all over the place. The music routine is really supposed to be called from a timer independent from the games fluctuating framerate but I thought this was too cool not to share.

nokturnal
Posts: 67
Joined: Wed Aug 12, 2020 12:30 pm

Re: Raven. A homemade Atari-like computer

Post by nokturnal »

Cool, I was thinking about doing the same for f030/ct60 build, but with external hardware (probably I will do it, because it is less involved than Doom). Apparently OpenTyrian has built in Adlib software emulation, which is quite interesting for reference / testing purposes. But i think it wasn't present in OpenTyrian 060 port by Insane for some reason (maybe it was too much)..
saulot/[nokturnal]
------------------------
www: https://nokturnal.pl
User avatar
agranlund
Posts: 874
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Raven. A homemade Atari-like computer

Post by agranlund »

nokturnal wrote: Mon Jun 10, 2024 6:34 pm Cool, I was thinking about doing the same for f030/ct60 build, but with external hardware (probably I will do it, because it is less involved than Doom). Apparently OpenTyrian has built in Adlib software emulation, which is quite interesting for reference / testing purposes. But i think it wasn't present in OpenTyrian 060 port by Insane for some reason (maybe it was too much)..
Yep, it ended up being minimal effort to reroute the games io-port writes to hardware rather than the Adlib software emulator.
I'll probably end up using Tyrian as a testbed for building some kind of GUS/AWE utility library too, for all the stuff you don't want to constantly have to rewrite or copy/paste over and over again.


I was thinking if it perhaps makes sense to introduce a simple OPL cookie with function pointers for register read/write?
It makes sense from an application perspective to not have to care about how the OPL is hooked up the the machine - it just wants to know if there is one and then read/write to its ioports, and ideally that should just work regardless of present or future ways of hooking up an OPL to Atari.
On a selfish level, I'd like for any programs I make that use OPL to basically just work also on my ST using your OPL adapter.
nokturnal
Posts: 67
Joined: Wed Aug 12, 2020 12:30 pm

Re: Raven. A homemade Atari-like computer

Post by nokturnal »

@agranlund I've already have hardware independent library for hooking up any opl2/3 device.. Write is not enough, because sometimes you want to know the opl state, so you need track it's registers somehow (it's not very crucial for games ofc if only write is needed). Most opl2/3 devices are read only (not an issue on ISA), but I'm not sure why, maybe because device simplicity and some chips are read only I guess. So, for example if OPL2/3 is connected sometimes is impossible to determine what is actually connected. Some tunes written for OPL2 will not replay correctly if you will not enable OPL2 compaibility bit, or there are dual chip setups. Right now I have driver structure, so on start you need only to pass (via commandline) what kind of device you are using and proper driver initializes opl according to chip type (opl2/3 or whatever). Interface for write is exposed (I've added immediate write and internal que, so messages are sent in a batch, it's useful for opl3 express, because there is an overhead for writes, much bigger than on let's say opl3lpt or cart). Still working on cartridge version (probably there will be OPL2 too, got schematics, but I'm missing some footprints). Recently I've added driver for FM Melody maker, but didn't test it yet (it's reduced cost OPL2 (OPLL)). But it's a toy in comparison to OPL2/3.. Basically everything is ready (driver part), but I didn't publish it yet. Embedding in application is trival.. You call init with device type(opl2lpt/opl3lpt/opl3 express/opl3 cart/opl3 duo!/opl2 audio board ...) you want to use, you receive interface(struct with function pointers), you call init from it and you can send commands to 'something' on the other side. Interface is the same for all devices, so opl integration is done once and works for all devices.. Atm drivers are statically linked all together, but I imagine that proper driver would be loaded at runtime (something what jam plugins does, but for hardware), I need to find a way to do it, because PIC doesn't work with atari cross tools(but it might changed in latest mintelf).. It's let's say on my todo list, it would reduce binary size and memory occupancy a bit.. I've also created a helper interface to manage opl chips much easier (shadow registers tracking and handling opl2/3 dual opl3 configurations).. The music players I wrote or adapted sit on those drivers (currently I have dro/vgm/rad (preliminary) and some more). Adding Adlib on ISA wouldn't be a problem, it needs some time. I have plans for adlib on vme/isa support for instance, but need to finish cart hardware (got some issues with current design atm).. It could be hooked on system level, but I was designing it I was thinking about easy opl integration with existing/future games/aplications.
saulot/[nokturnal]
------------------------
www: https://nokturnal.pl
nokturnal
Posts: 67
Joined: Wed Aug 12, 2020 12:30 pm

Re: Raven. A homemade Atari-like computer

Post by nokturnal »

And I also there is possibility to add opl2/3 software emulation, also within current driver structure.
saulot/[nokturnal]
------------------------
www: https://nokturnal.pl
User avatar
agranlund
Posts: 874
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Raven. A homemade Atari-like computer

Post by agranlund »

I think we're talking about slightly different things, or rather your implementation seems larger with more platform-agnostic helper stuff built-in compared to the simple (maybe too simple?) thing I had in mind. What you are describing certainly sounds like a very nice especially for when you are coding something from scratch.
Or maybe I am misunderstanding :)


My angle was more that if you break it down to the lowest level, the only thing that is actually hardware-dependent is the ioport read/write implementation for the interface that sits between the cpu and opl chip. All, or at least most, else is hardware-agnostic in application or helper-library domain.

Tyrian already interfaced with a hardware-accurate OPL emulator so making that work with real hardware was more or less just removing the emulator and replacing their outp/inp equivalent with one-liner functions that routed to the ISA bus.
No need for anything else - the game already did detection like Dos games normally have to do Adlib detection.
(It looks like it sets up the timer and checks the status port for for expected value but I really didn't look to carefully since whatever it's doing just works due to changing the lowest level)

VGMSlap player was basically the same in that I implemented functions instead of those x86 specific outp/inp instructions - but then, just like Tyrian, it was an existing codebase that already had to have all the higher level including OPL2, OPL3 and dual OPL2 detection in place which needed no changes from my side.

My point was that it would be nice to replace those one-liners with a call to some globally exposed function somewhere. A "driver" if you will, and the opl stuff in Tyrian and whatever else would work on everything present and future as long as something is implementing the low level read/write for the particular interface.

This is what's hurting my eyes basically.. pretty much the only interface-specific OPL thing in the Tyrian port (and VGMSlap too I suppose).
Everything else should "just work" regardless of how the OPL is connected since it all boils down to calls to these in the end.

Code: Select all

static inline void outp(unsigned int port, unsigned char data) {
    *((volatile unsigned char*)(0x81000000 + port)) = data;
}

static inline unsigned char inp(unsigned int port) {
    return *((volatile unsigned char*)(0x81000000 + port));
}
(I was just about to change the hardcoded 0x81000000 to use the isa_bios cookie interface instead, in the off-chance someone with a Hades/Milan/Panther benefits from it, but as I was doing that I thought of your cartridge interface and that brought to mind some kind of OPL cookie/driver/library instead)


Edit: you library does sound like a very good thing and I'd be happy to send over whatever you need to support ISA cards too.
User avatar
agranlund
Posts: 874
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Raven. A homemade Atari-like computer

Post by agranlund »

@mikro, cheers for mxPlay it's a terrific piece of software and the plugin interface was a breeze to use!

I have a few questions which may be silly, I'm not sure :)

Is there are way for a plugin to signal that a song is over, in case I am not sure (or too lazy) to try and calculate that ahead of time for the PlayTime() return value?
If there isn't can I add something like that, perhaps as some kind of return from the periodic call to Feed() or some other way that you prefer?

I am getting a sort of flashing in the background of the scroller and the time ticker.
It behaves the same with other themes and audio plugins too and I'm wondering if this is something known or if I'm alone with this, it does look like it's perhaps some kind of widget clear-and-redraw but with the "wrong" clear color.

I am using a slightly altered system palette from the standard nvdi one so I'll do some more tests here in regards to my desktop setup to see if it's any one particular of the components that is causing it.
(This is 8bpp Nova+Nvdi on N.AES + Thing on Freemint)


nokturnal
Posts: 67
Joined: Wed Aug 12, 2020 12:30 pm

Re: Raven. A homemade Atari-like computer

Post by nokturnal »

@agranlund yes I understand that. There is possibility to use only the subset of functionality and I get what is done in those ports. Yes single read/write port would be sufficient, but as I said only ISA cards have possibility to read opl2/3 registers, other devices are read only (like opl2lpt/opl3lpt), so detection in those cases isn't possible.. Writing to port is fine if you have certain stream of commands, but you still need to have possibility to adjust some things in runtime depending on opl type.
For example, when you are trying to replay OPL2 tunes (like vgm's) on opl3 without setting compatibility bit, there will be silence or something else. Additionally opl2 and opl3 have different timings (OPL3 needs no wait states, OPL2 needs them), so writing routine needs be different (and it's dependent on cpu speed, because OPL2 clock is slower than ST cpu).
And as ISA has possibility to read registers then it would be sane to not use shadow registers on cpu side..
If you could send me ISA snippets then I can add driver and send you player for tests, it might be fun..

Here is my driver interface needed to run any opl device, driver name, info about setup (single / dual), operation mode (eg. opl3 can operate as opl2), several function pointers, which pass opl data to driver and simple function/utility pointers, shadow registers (in case of ISA might be completely ignored):
FmLibDeviceInterface.png
FmLibDeviceInterface.png (60.51 KiB) Viewed 196 times
The rest are functions, for easier opl2/3 manipulation etc.. But you don't have to use them..
saulot/[nokturnal]
------------------------
www: https://nokturnal.pl
mikro
Posts: 505
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: Raven. A homemade Atari-like computer

Post by mikro »

agranlund wrote: Tue Jun 11, 2024 7:12 pm @mikro, cheers for mxPlay it's a terrific piece of software and the plugin interface was a breeze to use!
(humbled) Many thanks. Seeing my baby with new features added is really cool.
Is there are way for a plugin to signal that a song is over, in case I am not sure (or too lazy) to try and calculate that ahead of time for the PlayTime() return value?
If there isn't can I add something like that, perhaps as some kind of return from the periodic call to Feed() or some other way that you prefer?
There is not, unfortunately. All the plugins either provide the time or have no clue at all (the typical example is MOD -- there's no way to check when the module really ends). You can force the playtime in the cfg file but that's just a terrible workaround.

So yes, having a separate error code for "song finished" or something like that in Feed() seems like a good idea. Btw another highly-sought feature was a rewind/forward slider. ;-)
I am getting a sort of flashing in the background of the scroller and the time ticker.
It behaves the same with other themes and audio plugins too and I'm wondering if this is something known or if I'm alone with this, it does look like it's perhaps some kind of widget clear-and-redraw but with the "wrong" clear color.
Not a bug, a feature! ;-) https://sourceforge.net/p/mxplay/code/H ... gs.txt#l16 ... the text is updated by raw strcpy'ing into the TEDINF->te_ptext field, I didn't know better back then. Not that I know now but at least it would raise a red flag in my head. :) Maybe there's a way to do it cleverer, e.g. having two TEDINFO structures and swap between them?
I am using a slightly altered system palette from the standard nvdi one so I'll do some more tests here in regards to my desktop setup to see if it's any one particular of the components that is causing it.
Certainly not. Try the trick from bugs.txt, IIRC the best results were in MagiC (or XaAES?) in the bottom part of the screen.
Post Reply

Return to “MEMBER BLOGS”