Hi,

es gab mittlerweile mindestens 2 Spiele auf den letzten ABBUC Mags, die nur mit XBIOS laufen.

Leider läuft das eine nur mit XBIOS 1.0 und das andere nur mit XBIOS 1.6.

Darüber hinaus scheint XBIOS potentiell ladbare Dateien über das Verzeichnis einer DOS 2.0 Disk einlesen zu wollen.

Was mich an der Sache ein bischen anpieselt ist folgendes:

- XBIOS scheint zwar sehr viel kompakter und leistungsfähiger als .Net zu sein, aber unter der gleichen Inkompatibilität zu leiden

- die Games sind nun an eine Disk mit DOS 2.0 Dateisystem gebunden, womöglich auch noch mit 128 Byte / Sektor

Kennt jemand den Author?

Vielleicht kann man XBIOS ja auch so schreiben, daß neue Versionen abwärtskompatibel sind?

Und vielleicht kann man XBIOS ja auch so schreiben, daß man es mit der eigentlichen Datei auch zusammen mergen kann und es dann beispielsweise über die INIT-Adresse gestartet wird?

Es sollte auch das SpartaDOS Dateisystem können.

Und es sollte 256 Byte/Sektor können.


Alternativen
===========

Vielleicht können die XBIOS Games aber auch ohne XBIOS geladen werden?

Ich meine jetzt nicht über einen Speicherinhalt Dump des Atari, sondern in dem man dem XBIOS-abhängigem Game in der Datei die notwendigen Header für ein COM-File hinzufügt?

Viele Grüße

Erhard

Hallo Erhard,

ich verstehe die Problematik. Das macht auch beim Softwarewettbewerb Probleme. Ich werde XXL Deine Vorschläge mal weiterleiten.

Kann mal jemand einem Dummen erklären, wozu man XBIOS überhaupt braucht? Bzw., was für Vorteile man dadurch hat?

Hi,

Bunsen hat geschrieben:Kann mal jemand einem Dummen erklären, wozu man XBIOS überhaupt braucht? Bzw., was für Vorteile man dadurch hat?

leider bin ich nicht wesentlich weniger "dumm" als Du.

Augenscheinlich versorgt XBIOS einen mit Sachen, die man immer wieder braucht.

Es sieht so aus, als würde zum Beispiel interruptgestützter I/O unterstützt, so daß beim Laden des Programms bereits Sound oder animierte Grafik laufen können.

Keine Ahnung, was da sonst noch drin ist.

Viele Grüße

Erhard

Hi,

skriegel hat geschrieben:Ich werde XXL Deine Vorschläge mal weiterleiten

oh ja, bitte!

Viele Grüße

Erhard

Ja, aber dafür braucht man kein XBIOS...

Das hatten wir (also ich + Stefan Lausberg) schon in den 90ern in Turbo-Basic mit Assembler-Routinen für ein Disk-Magazin von uns umgesetzt. Oder auch Ariola-Soft hatten das bereits.

Man sollte echt aufpassen, nicht zuviel zu verwässern, sonst haben wir in zwei Jahren ein durcheinander, dass viele Programme hier nicht laufen weil blabla und das andere läuft da wieder nicht weil blabla...

Meine Meinung.

Hi,

powersoft hat geschrieben:sonst haben wir in zwei Jahren ein durcheinander, dass viele Programme hier nicht laufen weil blabla

Ich bevorzuge es auch, wenn Spiele eigenständig sind, nicht ungefragt auf Disk rumkritzeln und so portabel sind und gut laufen wie zum Beispiel die von Fandal.

Viele Grüße

Erhard

Na gut, auf die Gefahr hin, was nicht ganz richtiges zu sagen, hier mal was ich weiß (Stefan D. und Andreas mögen mich bitte korrigieren):

XBIOS ersetzt einige Routinen des Atari OS, und zwar komplett. Diese Routinen fehlen also. Das bereitete uns schon Probleme beim Softwarewettbewerb.

Warum? Weil XXL eine Methode hat, Spiele von einer anderen Prozessorbasis (Z80 - ZX Spectrum) auf den Atari (6502) zu portieren (z.B. Mazezam und Deathchase XE). Und für genau diese nutzt er XBIOS.

Ich persönlich bin nach allem was ich darüber weiß kein Freund davon, denn die Atari-Routinen sind in Ordnung und es gibt eigentlich keinen Grund sie zu ersetzen.

Letztlich ist es also für XXL eine Erleichterung um Spiele vom ZX Spectrum zu konvertieren, ohne sie komplett neu in 6502 Code schreiben zu müssen.

Ich hoffe, das ist nicht allzu falsch.

Nun,

als nicht-Programmierer habe ich kaum Ahnung von der Materie. Ich selber bevorzuge auch DOS oder GameDOS (ggf. Bootloader). XBIOS ersetzt hingegen DOS und Gamedos, denn es stellt bis zu 61kbytes an Speicher (eines 64k-Rechners) zur Verfügung. Dennoch ist es möglich, Dateien nachzuladen, Highscores zu speichern usw. usf. also alles, was ein GameDOS nicht kann oder wofür ein DOS zu viel Speicher benötigt.

Dennoch mag ich XBIOS nicht besonders, was wohl nur an alten Gewohnheiten liegt (ich mag aus denselben Gründen ja auch SDFS und dazu kompatible DOSse nicht). Mehr Infos findet man in polnischer Sprache hier:
http://xxl.atari.pl/?p=1076
oder im polnischen atarionline-forum (wenn gewünscht, mit Google-Translate):
http://translate.googleusercontent.com/ ... Zzw#Item_0
Natürlich gibt es auch Infos bei atari-age:
http://atariage.com/forums/topic/207232 ... try2671151
und hier: http://atariage.com/forums/topic/217484 ... try2845060
und hier: http://atariage.com/forums/topic/210835 ... try2847442

Immerhin erlaubt XBIOS auch ein Autorun, sofern man die Datei in XAUTORUN umbenennt und die neuesten Versionen kommen mit bis zu 128 Dateien in der Directory (Bibo-DOs Format) und auch DD bzw. 256Bytes per Sektor klar. Dennoch bin auch ich für reine Fileversionen, die unter möglichst vielen DOS oder GameDOS Varianten laufen und nicht allein an XBIOS gebunden sind. Bei Homesoft gibt es zum Glück gehackte/gepatchte Fileversionen von Mazezam und Deathchase, die ohne XBIOS laufen, Mazezam: http://www.mushca.com/f/atari/index.php?dl=393
und Deathchase XE: http://www.mushca.com/f/atari/index.php?dl=401

Gruß, Andreas Koch.

Hi,

ok, das sind ja schon mal recht viele Infos.

Ich hab mir mal die Übersetzung der Webseite gezogen. Jetzt muß ich die polnischen Elemente daraus löschen und die Übersetzung bereinigen. Wenn ich damit durch bin, werde ich das posten.

Die derzeitige 2.0 soll zwar mehrere verschiedene Dateisysteme und 256 Byte Sektoren können, aber immer noch kein SpartaDOS Dateisystem.

Ich werd mal prüfen, ob die 2.0 wenigstens die Kompatibilität verbessert, so daß Mazezam _UND_ Deathchase XE damit startbar sind.

Besonders gut finde ich, daß es einen Hack für die beiden Spiele gibt, der die Unabhängigkeit wieder herstellt.

Was in der Doku fehlt ist, wie XBIOS die zu ladenden Blöcke (Adressbereiche von - bis) erkennt: in der Doku steht so was wie "die Datei muß die Ladeadressen nicht beinhalten".

Viele Grüße

Erhard

Hi,

skriegel hat geschrieben:Ich werde XXL Deine Vorschläge mal weiterleiten.

hast Du schon was gehört?

Frag doch bei der Gelegenheit mal nach, warum Mazezam nur auf der 1.0 und Deathchase XE nur auf der 1.6 laufen.

Viele Grüße

Erhard

>Was in der Doku fehlt ist, wie XBIOS die zu ladenden Blöcke (Adressbereiche von - bis) erkennt: in der Doku steht >so was wie "die Datei muß die Ladeadressen nicht beinhalten".

XBIOS ist kein wirkliches DOS sondern ein DOS-API. Dementsprechend kann Dein Program per xBIOS beliebige Files laden. Und je nach File können das Daten, gepackte Daten (LZ4), COM usw. sein. Hier die Übersicht der API Aufrufe. Was blöd ist, ist das XBIOS standardmäßig bei $800 liegt und das eigentlichen DOS kaputt macht. Wäre besser, wenn man in Programmen die den DOS Speicher nicht selbst brauchen XBIOS z.B. an $2000 laden könnte und einfach wie eine API benutzen kann. Dann geht das mit jedem DOS (OK, außer Sparta) und man hat trotzdem die Funktionen. Ich hab Krystof mal gefragt, was er davon hält.

xBIOS_RENAME equ xBIOS+$03
xBIOS_LOAD_FILE equ xBIOS+$06
xBIOS_OPEN_FILE equ xBIOS+$09
xBIOS_LOAD_DATA equ xBIOS+$0c
xBIOS_WRITE_DATA equ xBIOS+$0f
xBIOS_OPEN_CURRENT_DIR equ xBIOS+$12
xBIOS_GET_BYTE equ xBIOS+$15
xBIOS_PUT_BYTE equ xBIOS+$18
xBIOS_FLUSH_BUFFER equ xBIOS+$1b
xBIOS_SET_LENGTH equ xBIOS+$1e
xBIOS_GET_FILE_OFFSET equ xBIOS+$21
xBIOS_SET_FILE_OFFSET equ xBIOS+$24
xBIOS_SET_PARAMS equ xBIOS+$27
xBIOS_SET_DEFAULT_DEVICE equ xBIOS+$2a
xBIOS_CHANGE_DIR equ xBIOS+$2d
xBIOS_LOAD_BINARY_FILE equ xBIOS+$30
xBIOS_OPEN_DEFAULT_DIR equ xBIOS+$33
xBIOS_SET_DEVICE equ xBIOS+$36
xBIOS_RELOCATE_BUFFER equ xBIOS+$39
xBIOS_LIST_DIR equ xBIOS+$3c
xBIOS_OPEN_DEFAULT_FILE equ xBIOS+$3f

first, xb is still being developed.

xB is not for users but for programmers. in next version programmer has full control on what drive allow game to work.
if do not use configuration bytes then any drive in atariOS (SIOINI ie. hdd) but there is possibility to
make game work on e.g. disk drive or e.g. cartridge - only. (or RAMDISK only
turbo case: in next xB if not change config bytes then ultra speed is on by default (if drive in AtariOS use it).
if programmer want use xB driver by default Ultra is OFF - may be ON by:
lda xHSPEED
bmi drive_has_no_turbo
sta xSPEED (you can use it in any time, even in one file swith speed every second [;)]
NMI case: nice in xB driver - do not use it on OS driver.
https://www.youtube.com/watch?v=CGQxSvA-Q8s
https://www.youtube.com/watch?v=4cIACQbmfH8
memory case: if use config bytes - load anywhere even to $0000. by default (OS driver) load > $c00
qmeg case: full support. you can run xB from any drive set by qmeg

filesystem case: familly AtariDOS/128 files/subdirectory, SpartaFS is to memory hunger. there is version for FAT and sio2sd but
I dont know if will be further developed.
once more: this is for programmer to make file handling easy with almost no memory require.
size case: next version has ability to split xB for size (autorun file must be on disk)
driver D: case: in next version not in standard - you need load D: driver
https://www.youtube.com/watch?v=FDWVolqrXyw
https://www.youtube.com/watch?v=RwuxoJBiPss


next version of xB will have:
- relocator of xB code, buffer address, run & init vectors,
- config bytes at headline, which I/O (OS or xB), name default autorun file, default i/o OS routine; NMI,IRQ,PORTB var
- sector alignment to the end of page
- all the time without using OS or page zero

it means... it is possible to load at $0200 to the end or load under OS at boot time.

without change config bytes at headline new xB will be much more "compatible" thanks to OS as default driver.

new xB takes even less space than current version (1kb).

Hi XXL,

xxl hat geschrieben:xB is not for users but for programmers

if xBIOS is required to start software that has been developed for xBIOS, then xBIOS is not only for programmers, because the user has to cope with the difficulties that come along with it.

xxl hat geschrieben:SpartaFS is to memory hunger

I know that it is much easier to read linked sectors while with SpartaDOS it would be necessary to read linked sector lists. But I've got everything on SDFS, including all file based games, which are started with a SDFS compatible game loader. I wouldn't like it if there were good games that cannot be loaded this way.

Compatibility

It is even worse that there are games that require a certain xBIOS version to be run:

- Mazezam only can be started with xBIOS 1.0. I only get some rainbow screen with 1.5, 1.6 and 2.0.

- Deathchase XE only loads with 1.6. It hangs flipping its start screens displaying some high-colored background with 1.5 and 2.0.

I have seen versions of these games that can be started without xBIOS, but these file consist of so many loading blocks, that there are merely more blocks than actual data.

While in general I like the idea of an environment that eases things quite much, those incompatibilies and the inability to continue using SDFS don't sound too good in my ears, I am sorry.

It would be great if we could find a way that those game files will be standard COM or XEX files again that can be loaded with any GameDOS, APE loader or SIO2SD XEX-boot-loader v2.x

Maybe it is possible that necessary xBIOS components are _part_ of the game file and are used (if necessary) running some INITs?

Best regards

Erhard

> if xBIOS is required to start software that has been developed for xBIOS, then xBIOS is not only for programmers, because the user has to cope with the difficulties that come along with it.

users gets disk or directory with xB library attached. programmer configute library he use - not user.


> I know that it is much easier to read linked sectors while with SpartaDOS it would be necessary to read linked sector lists.

SDFS eat to much memory. one of the primary xB assumptions was tiny memory consuprion.


> It is even worse that there are games that require a certain xBIOS version to be run:

similarly when the programmer will use some dos function whose function is not available in different dos, or work diferently.
as I said xb is still being developed. each next version has more features.
some existing features are being worked out. programmer chois which use. I suggest take the latest one
(will be available in couple of days).
I'm already very close to the final version.


> It would be great if we could find a way that those game files will be standard COM or XEX files again that can be loaded with any GameDOS, APE loader or SIO2SD XEX-boot-loader v2.x

copy xB and game to disk, rename game to xautorun. load dos or gamedos and run xb. thats it.

Hi XXL,

xxl hat geschrieben:copy xB and game to disk, rename game to xautorun. load dos or gamedos and run xb. thats it.

that's a clear _NO_, I guess.

I will of course check coming xBIOS versions, maybe things improve somehow.

If there are games which I cannot manage to load the way I want, well, sorry the programmer put effort in writing the game at all.

Best regards

Erhard

test version.

changes:
- If the device supports UltraSpeed - ​​xHSPEED variable holds the value HSIndex otherwise $ff (previously $00)
- sector buffer aligning the to the end of the page (before the beginning of the page)
- xB starts with the AtariOS I/O module, default module is xB (xSIOV).

new:
- new feature xBIOS_READ_SECTOR (and alias xBIOS_WRITE_SECTOR)
- header configuration:
- possibility to change the name of the file to automatically start
- possibility to change address of the xB library
- possibility to change address of the buffer
- possibility to change addresses INIT and RUN vectors
- possibility to change I/O module
- set value PORTB, NMIEN, IRQEN at xB first load
- relocator,
- opportunity to delete from library file: "MENU" and the AtariOS I/O

header :
.byte c'XAUTORUN ' ; autostart filename
.byte >$0800 ; where relocate xB (anywhere e.g under ROM)
.byte >$0700 ; where relocate buffer
.word INITAD ; change of binary file address initialization
.word RUNAD ; change of binary file address start
.word AOSV ; I/O module - AtariOS
.word AOSV_RELOC ; variables relocation for the AtariOS module (xBUFFERH, xDAUX2, xDAUX1)
.word xSIOV ; just for info - adress of default xB I/O module
.byte $ff ; PORTB do not alter BASIC bit
.byte $40 ; NMIEN
.byte $c0 ; IRQEN

which means that we can easily put xB lib and buffer at any adress even under ROM. At start library is compiled under $2000 and then relocated to location defined in header.

http://atari.pl/beta3.atr

Hi,

Happy Easter to everbody.

I tested 30b, but it doesn't seem to start properly: after loading, the cursor hangs in the upper left corner just after performing SIO command 3F and that's all.

Versions 1.0 | 1.5 | 1.6 | 2.0 do start in the same environment.

When I block SIO command 3F, than 30b loads further and I get a directory window.

However:

- loading DEATHCHASE XE crashes immediately with a dark screen
- loading MAZEZAM stops with rainbow colors

Just for your interest.

Kind regards,

Erhard

hi,

> I tested 30b, but it doesn't seem to start properly: after loading, the cursor hangs in the upper left
> corner just after performing SIO command 3F and that's all.

yes it's true. You probably use SIO2SD which is not full US compatible swith off US on SIO2SD.


> - loading DEATHCHASE XE crashes immediately with a dark screen
> - loading MAZEZAM stops with rainbow colors


as I say, xB if for programmer... use lib provide with game. if you absolutely want to use the new xB with eg. DC:

two ways:

1. attach this at the begining:

org $600
init1
jmp xBIOS_SET_DEFAULT_DEVICE
ini init1

or

2. define proper header:

default xB header:

nag_fname .byte c'XAUTORUN '
nag_xbios .byte >$0800
nag_buffer .byte >$0700
nag_init .word INITAD
nag_run .word RUNAD
nag_io .word AOSV
nag_io_reloc .word AOSV_RELOC
nag_PORTB .byte $ff
nag_NMIEN .byte $40
nag_IRQEN .byte $c0
nagl_xSIOV .word xSIOV ; dummy
nagl_rts rts ; dummy

custom for DC:

nag_fname .byte c'XAUTORUN '
nag_xbios .byte >$0800
nag_buffer .byte >$0700
nag_init .word INITAD
nag_run .word RUNAD
nag_io .word xSIOV
nag_io_reloc .word nagl_rts
nag_PORTB .byte $ff
nag_NMIEN .byte $40
nag_IRQEN .byte $c0
nagl_xSIOV .word xSIOV ; dummy
nagl_rts rts ; dummy

as I say, now xB if full configurable for projects.

Hi,

xxl hat geschrieben:You probably use SIO2SD which is not full US compatible

no I do not.

I use APE.

But APE answers with a speed byte of #$08.

Does your latest xBIOS version not accept a speed byte of $08 while previous versions did?

Kind regards

Erhard