Jump to content

Rybags's Photo


Member Since 29 Sep 2005
ONLINE Last Active Today, 5:53 AM

#2916707 How to do a splash screen while loading an executable

Posted by Rybags on Wed Jan 29, 2014 6:28 PM

When disk IO is going on a bunch of stuff in Stage 2 VBlank will almost always get skipped - part of that is the storing of Display List pointer from the shadow to real register in Antic as well as the colour registers to GTIA.


To fix is fairly simple.  Straight after storing to all of the shadow registers just have a short wait like:


wait  lda $14 ; low byte of RTCLOCK

cmp $14

beq wait


You need to do that during loading for any shadow reg changes.  The alternative is to store to the hardware regs as well.  You'd generally do that e.g. if you were cycling a colour register continuously during the load.


For your delay - waiting for the 2nd byte of Rtclock to change will have variable delay.  To ensure consistency, it's a good idea to set the low byte to 00.


Since you have that wait loop early on, you could just change it to:


lda #0

sta $14

wait1 lda $14

beq wait1

#2916164 What aftermarket floppy drives were made for the 8-bit?

Posted by Rybags on Wed Jan 29, 2014 3:16 AM

The Indus uses an onboard Z-80 CPU (Atari 810/1050 use 6507) - with the Ram upgraded it's possible to run CP/M on the drive.

Although I've seen drives in action I've not seen them running CP/M.  I imagine the Atari computer then becomes something of a terminal for input/display since the drive itself can only function as part of a computer.


AFAIK, Indus drives don't have extraordinary copying ability out of the box.  But I imagine with a Ram-upgraded drive that all sorts of things might be possible.

#2915315 Did the Aquarius have a real Zilog CPU or just a clone?

Posted by Rybags on Mon Jan 27, 2014 11:03 PM

Second-sourcing for Z80 and 6502 was/is very common.


In fact I don't know if Atari ever bought a 6502 from MOS for it's computer or console line.  That said though, almost all full-capability 6502s used by Atari were the 6502C Sally variant which was a slightly enhanced version with the HALT function that was used in most of the computers and 5200/7800 consoles.

#2915314 Questions and Impressions -- Commodore 128D

Posted by Rybags on Mon Jan 27, 2014 11:00 PM

1> 128 release was early 1985, 128D supposedly was late 85.  From my memory (was my last year in school) it sounds about right.  Around the same time as the ST and Amiga were gaining steam, and overshadowed somewhat by both.


2> Price depends on where you are.  Mid 80s US prices were often equivalent to UK Pound despite USD being worth barely half as much, so a much better deal was had by Americans than practically everyone else.

A friend of mine worked in a computer shop for a while in 86, I remember going to another shop and actually buying a plain 128 to satisfy an order they had, and it was something like $700 or $800, so the 128D here would have been over $1000 at release most likely.  That said, probably more like $600 give or take in the US on release.

3> 128 PSUs are actually in demand as they are good for expanded 64s that need more juice.  128D, no idea - I imagine the PS might have been built in which can be cause for heat issues and failure in older machines.


4> Price today for a good 128D can be $100 upwards.  Nicely integrated system as you mentioned.   You easily enough can pay $80+ for a C64 and 1541, 128D takes up much the same desk space in a much neater package.


5> Supposedly the entire 128 line sold like 3-4 million, maybe more.  Not bad considering how late to the party it arrived.

As for support - the 128 mode had little commercial software released.  Some games had 128 versions produced and some games detected the ability to run the CPU faster in 64 mode and did so.

In 64 mode on any 128, you can either run the CPU at double speed with blank screen or use Raster IRQs to switch the CPU to fast mode in the offscreen period for a 20-30% overall speedup.

#2915126 PILOT.rom with real hardware?

Posted by Rybags on Mon Jan 27, 2014 6:27 PM

Language ROMs are usually special case carts in that you can't just load and run without extra preparation.


Generally you need to change RAMTOP and re-open E: such that the screen is ~ $9C00, if the screen is left ~ $BC00 as in a 48K config then the program overwrites it and the user typing will corrupt the language program and probably crash it.


An easy way to do it can be to disable Basic while it loads, then re-enable Basic and have a CASINI routine that disables Basic again, calls DOSINI if required then runs the language via the cart vectors after disabling Basic via PORTB.


Doing it like that means the OS automatically will open E: in lower memory.  Generally with a cart you need a DOS, so it not working via menu loader isn't really a problem.

#2913366 Seaquest for the 800

Posted by Rybags on Sat Jan 25, 2014 2:42 AM

Bryan did Castle Crysis in 2004 according to Fandal's site.

I doubt he had any access to source code, in fact I don't think the source is available for many arcade games at all.


Slower 6502 in arcade games doesn't necessarily mean an easy port - they generally made the machines with specs required to run the game at hand.  Chances are the graphics hardware has features that the computer can't easily replicate.


Missile Command arcade version also runs on a slower 6502 but the graphics has special attribute area at the bottom for score/status and the multicolour resolution is beyond what the computer is able to generate.

#2911999 Stampede new 2600 conversion

Posted by Rybags on Thu Jan 23, 2014 6:59 AM

Same thing happens with ancient games to modern PC, and backporting is popular as well.


Part of it is just the technical challenge.  I know I had fun doing the Plus4 and 7800 ports to the A8.  I've also got a 2600 conversion in the pipeline.

#2911987 No DLI possible at all during Disk i/o?

Posted by Rybags on Thu Jan 23, 2014 5:49 AM

You need custom SIO routines which have to occupy RAM (disregarding some OS variants or ROM-based Doses where Ram use can be minimal).


The boot process isn't really a big problem, typically you just have the first several sectors at normal which will typically contain some turbo SIO stuff.


You can't just set a bitrate that the OS will subsequently use - every time a SIO operation is initiated via the OS, the Pokey registers are setup to operate at 19.2k mode.

#2909325 Does the SIDE/SIDE2 and Ult1MB work well w/MyDos?

Posted by Rybags on Sun Jan 19, 2014 8:05 AM

I've got SIDE, Ult 1 Meg and IDE +2.


I see no reason to use MyDos - given that you can use a ROM-resident SpartaDosX, why bother with MyDos?


The pain of migration isn't that bad.  I also don't much care for farting about with small partitions or disk images and the like.

If you're upgrading your I/O device technology, may as well go with the best Dos to support it.


As for PBI and SIDE, I've not played with that aspect - in fact my Ult 1 Meg hasn't been flashed since I got it.  But I imagine the PBI functionality would work with MyDos but someone who's played around with it would be better qualified to answer that.

#2909303 Question: How do you move lines of code/subroutines around?

Posted by Rybags on Sun Jan 19, 2014 6:58 AM

Bankswitching just means a different part of ROM becomes visible at a given range of addresses, there's various schemes for the 2600.


Switching banks is usually a case of just accessing a particular memory location and the hardware in the cart does the rest.


From a programming perspective it can get tricky with references to locations, many assemblers provide directives like .BANK to inform the assembler that another bank is in force, allowing assembly to the same addresses again.


Additionally you lose a certain amount of cycles when doing the bank switch so it's worth planning what bits of the program are to go in the new bank.

A good idea might be to move large portions of the VBlank stuff - but the other consideration of course is that you might have data that needs to be accessed and it might need to reside in the same bank.

But there's various schemes around - some switch the entire 4K where others allow e.g. 2K static and 2K switchable.  You might want to select a scheme that suits your needs.  Of course the other consideration is how easy implementing the given scheme is on a real cartridge.


I tried a Google Search with "atari 2600" "banking schemes" and it came up with some good links.

#2908429 Perplexity new Game at Fandal

Posted by Rybags on Fri Jan 17, 2014 8:45 PM



Looks pretty polished from the screenshot.  I've not got any emu stuff installed at the moment so will have to check it out later on.

Good to see the scene is very much alive and well.

#2907924 Question: How do you move lines of code/subroutines around?

Posted by Rybags on Fri Jan 17, 2014 6:18 AM

I remember doing the 480i + animation hack for Stellar Shuttle on the 8-bit computer.

I did it as a series of patches.  It became somewhat cumbersome and hard to debug.

That will be the same for anything once it gets beyond a couple of hundred additions/changes or even less.


It's much easier if you can produce some reverse-engineered source.  I've done it various ways on other things and it can be a rapid process with the right tools.

The problem with 6502 code is the indirect stuff - even the best AI won't be able to work out what z-page stores are just that and what ones are setting up indirect pointers which might move around when you change stuff.


But Stella can even help out there.  Thanks to the way it deduces code and graphic sections, it can help out - through deduction you can often work out what is setting up a pointer and what isn't.


Once you're done there, start modifying and the job will be much easier than hacking.

#2907911 Questions about Coleco graphics capacity?

Posted by Rybags on Fri Jan 17, 2014 5:29 AM

Bank switching within a cartridge isn't really a capability that's dependant on the host system, although it can help.


2 examples:  The Atari 8-bit computer has a specific line CCTL, that goes active whenever a specific 256 byte range of addresses is accessed.  Practically all bank-switching schemes use this as part of the logic for bank-switching.


Atari 2600 - no special control line, in fact not even a write line is provided.  But there's ways around it.  Bank switching can be achieved by using logic that senses access to a small range of addresses.  That is sufficient to provide what's needed although often a bit more expensive in terms of logic required in the cart.

#2907242 Did they ever use early x86 chips in arcade machines?

Posted by Rybags on Thu Jan 16, 2014 5:52 AM

8086 is somewhat weak compared to 68000 - essentially the 68000 machines would match or beat a '286 at double the clock speed.


68000 also easy to program for in Assembler compared to many CPUs.  And I imagine a good deal less expensive as well.

#2907237 Confusion about NTSC and PAL versions

Posted by Rybags on Thu Jan 16, 2014 5:18 AM

I have the suspicion I saw almost this exact post 2 or 3 days ago and replied to it in another forum section.


For the most part, no specific Pal or NTSC version.  Bounty Bob Strikes Back is a rare example of region encoding and it was only done as a measure against cheap importing.


Some problems do exist, particularly with modern games/demos in that NTSC might have problems due to less CPU per frame available but these problems are usually well publicised.


Atarimax flashcarts are one way to cheaply do cartrdiges although they only do 8K ones entirely from the flashrom.  There's also other alternatives.

Most old cart images are available with the self-destruct protection removed so can run based in RAM, so in effect any media type also.

Having actual cartridge is mostly handy for things you use a lot, e.g. languages and those few favourite games.

SIO2SD in turbo modes or even standard speed is probably as fast or faster than hunting around and swapping cartridges.