GEOS 2.0 for 8-bit Atari

[Atari8guy]

Having played with this for a bit now, it seems much more responsive than the C64 version.  Interesting how that works, this is a very cool project...

[flashjazzcat]

10 hours ago, Stephen said:

Dumb question - this does not hold true when loading off a PBI based HDD right?

Correct. You can take as long as you like to pull data off a CF or SD card. Serial IO - being timing critical - won't leave time for 20 NMIs per frame to move the mouse, etc (and I'm not prepared to force 1-3x SIO speed). And thanks to the elegantly designed Atari OS, the file system drivers need have no idea whether they're transferring sectors to and from a serial or parallel device. And even if that weren't the case, it seems inconsistent and kludgy to me to - say - let the mouse move during parallel IO but freeze it during SIO. I think it would be perfectly reasonable (in my GOS) - when the system is about to perform IO - to save the background of the software sprite mouse pointer, draw the pointer on the screen at that position, shut off the mouse interrupts, context switcher, etc, bank the OS back in, read or write the data, then re-enable everything. The upshot of that - in practice - will actually be that the mouse still appears to move, albeit slowly (with SIO) or jerkily (with PIO).

Edited November 16, 2022 by flashjazzcat

[Peri Noid]

[delete, please] 

 

Edited November 16, 2022 by Peri Noid

[atarixle]

On 11/15/2022 at 8:48 PM, flashjazzcat said:

Is there any particular reason GEOS can't call the SIO? It would thereby gain access to PBI hard disks, FAT-hosted ATRs, etc, without any new drivers having to be written at all.

 

 

My highly unexperienced guess is, that GEOS wouldn't even know how to handle something else than C64 DOS. All the file-handling-logic comes - if I remember right what The 8 Bit Guy said - from the Disk Drive itself.

The Atari 8 Bit has only basic access to a drive, so it has to load a DOS from disk to handle files at all. That is much of a difference and might take too much memory.

As GEOS is just a patched piece of C64 software, it might never work with Atari disks (just like the C64 Kernal ATARI64.XEX does not).

 

Nevertheless, it is freaking cool to watch GEOS work for real on my Atari 800XL.

Edited November 19, 2022 by atarixle

[ytm]

29 minutes ago, atarixle said:

My highly unexperienced guess is, that GEOS wouldn't even know how to handle something else than C64 DOS. All the file-handling-logic comes - if I remember right what The 8 Bit Guy said - from the Disk Drive itself.

The Atari 8 Bit has only basic access to a drive, so it has to load a DOS from disk to handle files at all. That is much of a difference and might take too much memory.

As GEOS is just a patched piece of C64 software, it might never work with Atari disks (just like the C64 Kernal ATARI64.XEX does not).

 

Nevertheless, it is freaking cool to watch GEOS work for real on my Atari 800XL.

Hi, author of the port here.

 

GEOS only requires block-level access to the disk. Commodore filesystem is implemented on top of that, but all you need is a block-level access to the device, so it doesn't rely on the disk drive implementation, everything happens on the computer side. You only need to have a function that takes track & sector as the input and returns 256 bytes of data.

 

SIO disk driver is not implemented because I'm a C64 person and I have no idea how to do it - how to discover devices, how to prepare the ROM call for read/write, how to handle errors or disk change. Or maybe it's better to drive the I/O registers directly, I don't know.

That's why I invite the community to figure this out and send pull requests :).

 

Regards,

ytm

 

 

[ol.sc]

Hi,

 

I presume that most of you aren't aware that Berkeley Softworks ported GEOS also to the Apple II. However, given CBM GEOS programs never run on the Apple II as-is. There's way less information available about Apple GEOS than there's about CBM GEOS. Especially there was never a geoProgrammer published for the Apple II. However, I invested quite some effort in getting enough information (see https://github.com/cc65/wiki/wiki/Apple-GEOS-Symbol-Table and https://github.com/cc65/wiki/wiki/Apple-GEOS-Zeropage-Usage) to allow to port Maciej's GEOSLib (https://cc65.github.io/doc/geos.html) to the Apple II. There are fore sure (many ?) things not working as expected, but I'm not actively working on the project anymore.

 

It was mentioned in this thread that GOES contains its own filesystem that "only" requires track/sector I/O routines. However, that doesn't mean that GEOS disks are totally incompatible with "usual" disks, rather the opposite.

 

I don't know about CBM GEOS, but Apple GEOS uses the Apple ProDOS 8 "kernel" for disk I/O. And it for sure doesn't only use the track/sector I/O routines from ProDOS. Rather it uses the file access routines from ProDOS 8. However, in a way very simliar to CBM GEOS, there are subtile incompatibilities between Apple GEOS disks and usual ProDOS disks (see https://github.com/cc65/wiki/wiki/Apple-GEOS-File-Formats).

 

So a typical GEOS user both on the CBM and the Apple II expects to be at least able to add some files to a GEOS disk from outside of GEOS and use them later in GEOS.

 

Note: I've toyed many years with the idea to port https://github.com/mist64/geos to the Atari, turning cc65 + GEOSLib into a GUI development toolchain targeting all three major 6502 desktop systems. However, I would have never believed that it would be possible to run (many/most) CBM GEOS programs on the Atari!

 

Regards,

Oliver

Edited November 25, 2022 by ol.sc

[Kaz atarionline.pl]

Hi guys,

 

From now you have English and other translations of Maciej's conversation with me and Mono. Substitles are in Polish, but on YouTube you can enable automatic translation into other languages, including English, German and Spanish. Thanks to Misza for his great work with Polish subtitles.

 

 

[Lynxpro]

On 11/15/2022 at 5:46 AM, atarixle said:

Technically, BOSS-X is a collection of similar looking Turbo-BASIC programs, while GEOS utilizes a Kernal for providing commonly needed functionality in GEOS programs.

 

Turbo-BASIC is made especially for Atari 8 Bit Computers, GEOS is portable between 6502 platforms (well kind of, probably more portable than the original authors were thinking of).

 

BOSS-X is written and running in BASIC, GEOS is a machine language system.

GEOS was commercially successful with lots of apps while the targeted platform, especially the C64, had its commercial high-times, and was still in production. BOSS-XL/XE (1993-1999) and BOSS-X (2000-2022) were initiated when the Atari was already a historical machine.

 

GEOS had quite usable, well working office apps. Still the C64 didn't find the way into work-offices, but private ones.

BOSS-X offers just a desktop and a filemanager, a ton of File-Viewers, which have been re-invented by Apple as QuickView, and some utilities. But I never made it to create a simple plain text-editor in BASIC for BOSS-X or stand-alone.

 

GEOS is a commercial, usually copy protected product, BOSS-X is a free hobby-project and installable w/e you want (as long it is not SpartaDOS).

 

And it seems like GEOS is still in use and development, while BOSS-X development will stop in 2022.

 

There's an active GEOS user group on Facebook. Many of them are using Commodore REUs or GeoRAM carts to go way beyond the standard 64K or 128K RAM... even beyond 1MB... to 2MB+.  A lot of them use C128s for its 80-column C128 mode. If I'm not mistaken, GEOS Wheels is the last non-x86 version.

 

GEOS was also available for the Apple II line. They didn't seem to bother with the IIgs since that already came standard with the official Apple GUI. Not sure if it was ever ported to the BBC Micro. We all know it wasn't officially released for Atari 8-Bit but there certainly were rumors over the years that a version was at least considered to some [probably minimal] extent. I wouldn't be surprised if Commodore told them to nix any potential Atari port or kiss the bundling deal with the C64c goodbye...

Edited November 28, 2022 by Lynxpro

[atarixle]

On 11/19/2022 at 9:10 PM, ytm said:

Hi, author of the port here.

 

GEOS only requires block-level access to the disk. Commodore filesystem is implemented on top of that, but all you need is a block-level access to the device, so it doesn't rely on the disk drive implementation, everything happens on the computer side. You only need to have a function that takes track & sector as the input and returns 256 bytes of data.

 

SIO disk driver is not implemented because I'm a C64 person and I have no idea how to do it - how to discover devices, how to prepare the ROM call for read/write, how to handle errors or disk change. Or maybe it's better to drive the I/O registers directly, I don't know.

That's why I invite the community to figure this out and send pull requests :).

 

Regards,

ytm

 

 

SIO access shouldn't be that hard, I did that once in BASIC. Basicly you POKE sector number and device-letter and -number to a certain value, I guess you also set the bytes per sector, and let the Atari OS do the rest.

256 bytes per sector are only accessable via enhanced hardware which never was standard back in the 1980s and only was supported by late disk drives, but nowerdays everyone has access to 256 bytes per sectors devices defacto.

It would be really nice to save a GeoWrite doc on a real storage device.

 

When at home I could look for the correct memory locations.

Edited November 29, 2022 by atarixle

[+CharlieChaplin]

Is it only me (or better my ears) - or is there an awful annoying, ear-killing buzzing sound when running GEOS on the A8 ? Since the XEX uses $1800-19xx, it does not load from DOS. So I loaded it from a bootloader and from uDOS, but both times I got the awful noise...

 

Besides, any updates or further work on this project ? Would be cool if GEOS on the A8 could also get SIO working somehow... (and besides joystick in port A also mouse support for port B, e.g. ST or Amiga mouse for port B).

 

[_The Doctor__]

perhaps LiteDos or similar would help?

[+CharlieChaplin]

Also, when Geos-130 or Geos-320 XEX-file has finished loading, the program appears on the screen (and the buzzing noise from the tv speaker starts!), but the 1050 drive does not stop loading, the busy LED of the 1050 still lights and the drive still loads (or tries to load)... ?!?  One can simply switch off the floppy drive then, since all data is in XRAM, but in my eyes this is a strange behaviour.

 

[_The Doctor__]

Is it also possible GEOS would like to be on a double density or double density double sided drive... maybe things get truncated?

[+CharlieChaplin]

Ha, found the source of the "bzzzzzzzzz" buzzing - the connected 1010 Data Recorder. Disconnected it and the buzzing sound was gone. Don't know why Geos talks to the data recorder. Maybe it wants to know "is there anybody out there?". 

 

The disk drive still does not stop spinning, even when the disk is removed from the drive. 

 

Besides, uncompressed GEOS 320 has a size of 261KB, compressed with Exomizer approx. 142KB, thus a DD or DSDD disk is required for Geos 320 anyways.  

 

[_The Doctor__]

Maybe it thinks it's a VIC 20 and has tape issues?

Something must be disturbing the tape registers or some SIO serial rate issue like on reverters/850's. I'd say it might need to be completed or if it's truly a bug, fixed.