Jump to content

Rybags's Photo


Member Since 29 Sep 2005
ONLINE Last Active Today, 3:24 AM

#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.

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

Posted by Rybags on Thu Jan 16, 2014 12:45 AM

8080 was a forerunner of the x86 series and used in some earlier machines - Z80 was upward compatible with 8080 code and developed by some of the same team so in a way is a forked development but essentially the 8086 and later CPUs bear little relation to it.


I can't think of anything off hand that used x86.  The thing is that the x86 CPUs of "current generation" were usually very expensive in comparison to the competition.  Think hundreds of dollars vs tens for the like of Z80 and 6502.


It was just cheaper to use multiples of the other or custom ICs as assistants than to use an x86.

#2907143 When did the PC market get "stupid"?

Posted by Rybags on Wed Jan 15, 2014 11:58 PM

Clones, IBM replies with MCA with the PS2 that crashes and burns.  Pretty early on, really.


But agreed with the mass-market theory too - once you let the marketroid retards into the game with their stupid buzzwords, the whole thing goes to the dogs.


Just look at the modern day situation.  Capacities or network ability usually quoted in bits rather than bytes since it gives a bigger number.

K, M, G all bastardised such that they're no longer powers of 2 but actually thousands, millions, billions - once again all in aid of giving a bigger number that sells better.

Pissant capability graphics cards with 2 Gig of RAM that's usually 2 or 3 generations old installed.


MMX in itself was a joke, same with NetBurst.  Stupid buzzwords that barely relate to what a feature provides.

#2906987 What was your first exposure to the PC?

Posted by Rybags on Wed Jan 15, 2014 6:26 PM

Hands-on, probably not a lot until about 1986.  There was a work machine which was probably a turbo'd 8086 clone with floppy, small HDD of 10 or 20 Meg.

I developed a version of one of my games in Basic, unsure what version but it allowed defining and plotting soft-sprites which made things easier.

Never took a copy away so it's likely lost forever.


Next up was probably a couple of years later, likely '286 clone which I started doing config diagrams on using some app under GEM.  From memory it also had Windows, probably version 1.


After that, another workplace got several machines in around 1990 - some '286 and '386.  Leaderboard Golf, Wolf3D and Doom were probably the most played games there.  Also spent a lot of time dialing into various BBSs.


I didn't really bother getting a machine at home until 1998 or so.  Practically always had access to plenty of gear at workplaces and for games had the Amiga and PS1.

I didn't really take PC gaming seriously until Wolf3D came along.  I knew that an 8 MHz ST or Amiga had next to no chance of matching that.  Once Doom came out it became obvious that the competition was gone and the future of desktop gaming was here.

#2904413 What *don't* you miss about CRTs?

Posted by Rybags on Sun Jan 12, 2014 4:08 AM

Size, weight, heat, power consumption.


Although that said, I have my 32" LCD in the same cabinet (modified to fit) that I had the CRT in, although I'm able to move it closer to the wall.


Power - actually it's probably close to double the Watts for the LCD but it's probably triple or more the screen size.  I've got 3 LCD monitors which save power vs the slightly smaller CRT I used to have on.


Other stuff like the occasional high-pitched hiss are good to be rid of.


Also, LCD monitor = significantly less eyestrain.  Probably a combination of things like less emissions, no flicker and much easier to read small characters.


Forgot to mention - curvature, glare.  There's probably more.


The downside of LCD is nothing compared to the advantages.  Also throw in price.  In 1998 I bought the 53 cm CRT for about 500 bucks, which is around the same I paid for the 32 inch LCD TV about 5 years ago.