Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

19 Good

About gpounce

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Thom, Yeah I will be hooking up with you all, just need to get the server into a more final state so I have something to offer. I intend to integrate a service that fujinet can mount, sio2bt xio conformance, maybe support for a couple of the emulators. I'm not much interested in running emulators but it sure would be handy to have a couple running do do compiling etc. A3s offers support for any # of "stations" ie atari systems concurrently in use, disk index searchable for description, filenames, collections. Right now its supporting the entire Holmes collection (10,000+ images), there are some oddball images on there for sure. It runs out of a tty using textual commands so can scale to multiple systems and many disks a lot more easily than the click-and-drool interfaces. Still have to add "all station" support eg mount a given disk on all stations with one command and so on. Eventually it would be nice to cleanly support faster pokey divisors but thats a ways off. Greg
  2. I've been doing a bunch of work on the a3s software; SD and DD working, xex, atr and xformer images all working with the various disk sizes they implement. I'm polishing, debugging, enhancing the command interface to get closer for a release. I started the N: driver I want to write. The open & status handler entries are working as expected but I'm finding the close vector is not being called; eg OPEN #1,4,0,"N:XYZPDQ" turns into a call to the open vector and I perform an SIO transaction to the server to set up the network connection, STATUS #1 calls the status vector and I can do a SIO status transaction to fetch that info- but CLOSE #1 doesn't call the vector. I am returning NOERR in Y from all these routines. From looking at the various docs it seems like I should get a call thru the close vector so I assume I'm omitting some detail. Any hints would be much appreciated... thanks! Greg
  3. I'm using AMAC D downloaded from the atariwiki page (many thanks!) - no problems with protection; I'm running on my homebrew disk emulator with an 800 and it is not reporting any strange sector reads The MACRO/ENDM issue arose on AMAC A, so I started looking around & found D which I updated to on general principles- I continued having the macro issue until I capitalized the macro labels. The error asserted by AMAC was an unterminated macro (my source has 2 macros- used to save and restore a stack frame). Intererestingly the macro references elsewhere in code are in lowercase, the definitions are in uppercase. I've disassembled the output .obj file, the macros are substituting in properly. I chose AMAC because I'm not into line numbers so do the editing using the program-text editor on my 800XL, assemble with AMAC on the 800, both mounting the same floppy on my disk emulator which handles that sort of use. That way the 800XL stays in the editor, and I assemble and test on the 800. Wouldn't mind interfacing a system emulator to my disk emulator so I could avoid exiting/restarting it.
  4. I had consistent failures of MACRO/ENDM using AMAC A and C (and I had a tab char <esc><tab> inserted just before the ENDM text), until I capitalized the macro labels. Didn't matter if the macro definitions were early or later in the file.
  5. beg pardon for a possibly stupid question, but is there an atr or similar containing vbxe control/config programs suitable for stock machines? i've found the vbxe games but not utility programs... if the vbxe can be configured via an autorun.sys that would be fine for me... thx!
  6. i am on ntsc, with a vbxe on an 800xl. no other mods or interest in additional devices or loading software to reconfig it, but would prefer the correct palette. otoh the pal colors are sufficient but not preferred. there is already a ntsc/pal jumper on the device, why not select the correct pallete on that basis?
  7. The 400/800/XL systems had a port of the Apple library "Supergraphics", Paul Lutus on the Atari. He implemented a driver 'G:' into which application software would write instructions for rendering of 3d vector shapes, rotation, translation etc and included a bunch of text coloring options too. The demo it shipped with was pretty snazzy, in digging thru my old floppies I discovered a game I was working on which used a bit of it- never went anywhere but I'd sure like to hear of anyone using it on the Atari- or Apple for that matter.
  8. VBXE instructions worked... took me a while to realize the R/G/B signals should NOT connected to the RCA inputs on the GBS board, but instead go to the 5 pin header, which includes the Csync signal. Adjusting the 3 pots all the way counterclockwise as per was very helpful to brighten the screen Tempest elite looks good- still have to adjust the color balance but the display is very nice. I had tried a RGB to HDMI converter from amazon, didn't produce a usable display- the GBS-8200 is a big win. Thanks all!
  9. ttl voltage level usb to serial cables are easily available- using the Prolific chipset. they are 2-wire; rx data and tx data only, so software expecting the COMMAND signal wont be happy- but if its possible to ignore command the the flying leads of the cable can connect directly to the SIO port. note that the flying leads will need something to adapt then to the SIO pins.
  10. The Holmes collection has a bunch of 1040x128 and a few 1140x128- at least the ATR header is authoritative with respect to sector size. Sounds like nonstandard counts above 720 should probably round up to 1040. As far as 1040 and 1140, I just load them in and permit the respective sector counts- the 800 and 800XL process them fine. I <think> a small number of the 256 byte sector images have the 1st 3 sectors also 256- a documented error case. Closer checks of disk size does allow deducing this case at least some of the time. At the moment I am not honoring ATR4 bad sector parms- I've not put any work into trying to deduce ATR revision from the image but probably should. I did see a number of them with sector counts 90 or less- so the rule at the moment is to assume 0 fill sectors up to 720 for those. I still have a dozen or so old floppies to archive, at least those will go into the usual 720x128 ATR1 format.
  11. I'm moving forward with the linux back end of my SIO networking idea; For test media I downloaded the Holmes CD collection (7,000+ titles), comprising a huge variety of disk sizes. My software is able to index & allow convenient searches of them, all but a hundred or so are bootable via my software on my 800 and 800XL, the exceptions having invalid signature words or hard disk images. I had to work through a variety of unexpected format details. I understand the ATR header format, but there are many of the images that use values of the Size field that do not correspond to the length of the disk image. In some cases the interpretation is obvious- a disk image being smaller than the Size*16/sectorsize implies the sectors not supplied by the image file should be presented as zero fill when read by the Atari- and this method is working so far. However in many others the computed sector count is very strange- I see cases of 512 secors, 718 (on 720 sector images), some have less than an extra sector of data appended to the image which makes the image portion of the file slightly larger than it should be. In such cases I ignore the surplus bytes, which seems to work but I wonder if there is a better method. My approach so far is to round the sector count up to the next valid size eg 718 is rounded to 720, adding 2 zero filled sectors. I was wondering if some of the very small images should be handled that way as well- and if computed sector counts over 720 should round up to 1040 or 1140. Perhaps there is a general rule for this? There are a number of cases where the disk image portion of the file is 2* the size given by the ATR header, is there a standard method for handling these files? I was wondering if this might be a double-sided image, but don't have an idea of how to handle that. The XFD format is a bit more straightforward, my impression is that the disk parameters are deduced from the filesize- since there is no header. Are there cases of odd-sized xfd files like in the ATR case? I do have per-image overrides for sector count and size so I can force particular parameters if the software deduces incorrectly but this seems like a mess to get right. Once the disk support is where I want it, then I'll release via GPL and git, then start in on the peer-to-peer network driver which is why I'm doing this. Might be good to add a TNFS server so a3s can serve sectors to the SIO wifimodem which looks pretty cool
  12. I used Datasoft interlisp for programming projects at college, IIRC I used edit.lsp as suggested. The biggest of the projects was fairly small- as I recall the problem was to define a 2d playfield divided into a matrix, with "items" dispersed across it. The program was to implement methods that a robot arm might use to pick up items and stack them; eg move to x,y, drop arm, grab object (or drop object) and so on. Compared to a modern Lisp its very limited but the essentials are there. I use Lisp whenever I need a high-level language- its very good at handling complex data of varied types- and the numeric types are fantastic. Its hard to beat C++ as far as work done per clock cycle but if thats not a major concern I find Lisp a lot more effective for algorithms and data processing than Python or Java. Its also a LOT faster than Python, which is a big help- and the cross-platform compatibility is surprisingly good. As far as working with clisp (or sbcl for reasonable levels of compiled performance), the usual procedure is to edit the .lisp file in your editor of choice, then '(load "project.lisp")', and invoke some top-level form to start the program. For production runs, the interpreter (or sbcl) is invoked from a shell script which runs the top-level form there. I use Lispworks which has a fancy compiler and binary generation system, as well as the usual GUI tools. Some folks have IDE's for clisp under emacs etc- but I prefer TTY methods even in gui environments writing graphical apps.
  13. I like that TNFS- having been down deep in NFS I profoundly appreciate its simplicity! For this purpose it seems as if it could be implemented for disk-sector size I/O blocks, maybe not even implement the directory functions, though something directory-like to permit some kind of image search and selection from the atari would make sense. Given the relative speed of the wifi and (presumed) PC on the back end and your device, the backoff protocol might be skipped as well though I would expect the block sequence numbering & perhaps retry to be important.
  14. I had some timing related issues similar to that, mostly was due to not honoring minimum delays between command & ack, and complete & data. I ignore the command signal and instead framesync the commands using the checksum byte (my SIO cable does not connect command). Concur that in a daisy chain situation honoring the command signal is important.
  15. Slowly closing in on finishing the disk support. I'm completing details relating to creating new images, metadata write-protect vs write-protect set in the ATR header and so on. I tracked down RWTEST to do some benchmarks, I'm getting DOS writing 1493 B/sec DOS reading 1613 B/sec DOS average 1553 B/sec on a (c) 2016 rev of RWTEST running on '83 vintage DOS 2.6f on the 800XL. This DOS has a drive speed option in the menu, which reports 778rpm - its certainly loads faster than a 810/1050. My host system is a x86_64 core2-duo linux machine, a3s doesn't noticeably touch the cpu when serving sectors so its nowhere near cpu-limited. I'm using 1ms delays between the ack/complete/sector transfers. Dropping below that seems to overrun the XL, so this looks like a local maximum in the performance space.
  • Create New...