Jump to content

Rybags's Photo


Member Since 29 Sep 2005
ONLINE Last Active Today, 8:48 PM

#3726922 Bad Disk Formatter

Posted by Rybags on Sat Mar 25, 2017 8:22 PM

Yep, you have to wait for the drive to return the info.  And you only get a maximum of 64 (?) returned, although using a disk with more than several bad sectors would be a pretty bad idea.


Have to wonder though, why Atari's Dos didn't use it with it's format command.  I suppose given that the default for years was to use write with verify plus they went with a piddly density to start with, there was a bit of paranoia about it.  There would have been a bit of extra programming needed but I would think that most of what's needed would already be present in the FMS.

#3726431 Bad Disk Formatter

Posted by Rybags on Sat Mar 25, 2017 6:19 AM

You'd need a small ML component at least for the disk I/O calls.


All that's needed is to write the boot sector and VTOC sector/s, then zero out the directory sectors, optionally zero out sectors 2, 3 - so it could be done algorithmically and fairly compactly.

The real trick would be to do one that handles the different Dos formats as well as the different densities and sector sizes.

#3726222 Bad Disk Formatter

Posted by Rybags on Fri Mar 24, 2017 7:30 PM

5. HCF





#3726202 Bad Disk Formatter

Posted by Rybags on Fri Mar 24, 2017 6:57 PM

I'd use them but only for stuff where it doesn't matter if the disk is lost like downloaded games.


What such a program needs is 3 paranoia settings -

1. mark returned bad sectors unusable.

2. mark entire track unusable.

3. mark adjacent tracks unusable as well.


Possibly an option for adjacent sectors too but that would be something that varies depending on interleave.

#3725746 atari basic vs commodore

Posted by Rybags on Fri Mar 24, 2017 5:29 AM

Directory listing from Atari Basic:

CL.#1:CLR:DIMF$(18):F$="D:*.*":O.#1,7,0,F$:FOR I=1TO66:IN.#1,F$:?F$:N.I


OK, way late with this one.  But back in the day I used this, fast to type in but runs a little slower:




Of course in both cases you get an error.  In fact, if you've just run a program that's used TRAP it might be a good idea to do TRAP 44444 to ensure the EOF condition doesn't cause the program to be started at the trap destination.

#3725553 Using keyboard for controls instead of joystick

Posted by Rybags on Thu Mar 23, 2017 7:55 PM

Those types suffer too but it's equivalent to joystick.  It's fixed speed movement vs variable for paddle.  About all that can be done is assign fire button or Shift which can be held to give slower or faster velocity.

#3725533 Using keyboard for controls instead of joystick

Posted by Rybags on Thu Mar 23, 2017 7:34 PM

Keyboard isn't a very good control method on the Atari because the time-saving Pokey key scan in fact limits detecting multiple key presses.

That means multiplayer simultaneous kb games are near impossible and single player ones are cumbersome.


Exceptions are - the console keys are always independant and not affected by each other or normal keys.

- Shift key can be detected independantly but there's no differentiation between each of them.

- Control key can only be "assumed" by it's bit in the keyboard code.  You can release Ctrl but keep holding the normal key and it'll still return the code indicating Ctrl is being pressed.  Ctrl key on it's own or with console key returns nothing.

- Shift + Ctrl + third key won't work for keys that are on the same scan row as them, ie - Help B V C X Z J K L ; + *


So, keyboard is sort of a poor arcade input method.  For something like a Galaxian type game it would be OK since the directions aren't needed at the same time and you could use Shift as the fire button.

#3724076 RastaConverter Feature Request

Posted by Rybags on Tue Mar 21, 2017 11:50 PM

Gr.7 would be pointless.  On the start of mode line the DMA penalty is exactly the same as Gr. 15.

On the second mode line, guess what?  You'd need an entire different bit of code to get the required register changes.

In fact, there would be plenty of cases where the same timing wouldn't be possible.


It would be next to pointless IMO - you'd have a chunkier display and the colour changes would be different on half or more the lines and just not look right.

And the overall memory footprint wouldn't be much smaller, in fact with NOPs and 2-byte instructions needed on the other lines to align timing the overall saving would probably be less than 2K.

#3721893 Printing to PDF, either in emulation or hardware?

Posted by Rybags on Sun Mar 19, 2017 8:42 AM

Altirra lets you have a printer output window and Atari800Win+ allows printing to a file that then gets opened in Notepad.

OK for text but probably not real good for graphical stuff or output full of printer commands.


I've got Foxit PDF creator installed on my PC and it has a PDF writer dummy device which allows printing to a PDF file.

I've not used it in any way so can't really comment on it.


PDF has the advantage that it's "portable" but the disadvantage in that they can be a near total PITA to do editing on.

Whether a virtual driver could take Atari print output and create anything useful, I've got no idea though.

#3719724 Trying to make Atari RU-fonted

Posted by Rybags on Thu Mar 16, 2017 5:24 AM

The problem with memory management is that Doses, language carts or executables can and probably will mess with your work.


MEMLO is generally modified by Dos at the end of successful boot, it'll usually be bumped to allow for the DOS and buffers resident in low Ram.  The consideration for modifying this with a program is that you need to cater for whatever memory Dos would want to use which can be tricky as every Dos is different and most can differ depending on how many drives and file buffers are enabled.


MEMTOP is maintained by the OS, it will be set when a screen or editor is opened and should point to 1 byte before start of the Display List.


RAMSIZ represents the page address of the first non-contiguos Ram address, established at cold and warmstart by the OS then copied to RAMTOP shortly after.  Best not modified, use as a reference showing how much contiguous Ram is available starting from location $0000.


RAMTOP represents the end +1 of screen memory.  When reserving Ram above the screen for graphics or other, RAMSIZ should be used as the starting figure then RAMTOP altered immediately before re-opening the screen in order to relocate it.  The reason to not use RAMTOP as initial reference is that it can cause storage creep (loss) in subsequent program runs if no warmstart occurs between runs.


APPMHI represents the highest address used by the application.  It's used to protect programs and variables/workspace from inadvertantly being wiped by a screen open operation.  The 400/800 OS has a bug where if this is set too high the screen won't open and the machine can be rendered unusable after a warmstart.

#3717662 bbc micro game help

Posted by Rybags on Mon Mar 13, 2017 5:33 PM

I don't get it, at the start of the thread it was all about the BBC, now it's Atari related questions.

#3716298 bbc micro game help

Posted by Rybags on Sat Mar 11, 2017 9:58 PM

There is no PEEK or POKE on the BBC, it's done differently, using Indirect Operators.


Use ? for byte, ! for word, $ for strings.  & can be used to convert to hex.



?16384 = 255

equivalent to POKE 16384,255



equivalent to D=PEEK(16384)



eq to POKE 16384,240


PRINT ?&4000

if done after should return 240



will store the string starting at that address, followed by CR ($0D).  Unsure if the Return character can be omitted.

#3713851 Bosconian for the 8-bits

Posted by Rybags on Wed Mar 8, 2017 4:37 PM

The game is sufficiently good though to deserve a quality original music piece for a theme.

#3710282 Notepad++

Posted by Rybags on Sat Mar 4, 2017 12:58 AM

OK, another bump and request.


I'm configuring to use MADS with Notepad++ - I want to open the assembly output in another tab.  The method I'm working on isn't the prettiest but I can't think of any other way.  I tried directing MADS -l output to CON: but it didn't work, and in any case the console output for Notepad++ isn't really suited for long outputs we'd get from bigger projects.


ie I've got a command sequence setup that goes to plugin npp_exec:



D:\Emulators\Atari 800\PC Tools\MADS 2.06\mads "$(FULL_CURRENT_PATH)" -l:$(NAME_PART).lst
notepad++ "$(CURRENT_DIRECTORY)\$(NAME_PART).lst"

This works (I had N++ set to operate in single instance mode) but the problem is if I don't close the tab with the output listing the next one that's generated isn't opened.


Ideally it would just close off the listing if a tab was already opened before calling MADS.  Whether that can be done I don't known.  Seems documentation for N++ and plugins is all over the place and much of what I've found is just by searches and luck.


Alternatively, I might just go back to EDIT+ which is what I was using previously.

#3708838 Anyone likes to hack a new demo?

Posted by Rybags on Thu Mar 2, 2017 5:11 AM

Pretty cool, though I wonder if it'll work as well with sharp edges.  Though we can easily do out of focus effects with the right adjacent colours not to mention RF video gives you shitty focus for free.