New C64 emulator for A8

[carlsson]

The VIC-20 can double buffer colour RAM. Just sayin'. ?

[carlsson]

Here is another C64 + Atari special. It runs slower than I had expected. Normal interrupt is at $EA31 but this environment has moved start of the routine to $E9FE which is yet one more thing to watch out for. Also I presume that ANTIC registers aren't always readable unlike some VIC-II registers so I could not INC directly to 53274 but had to use a temp variable to increase last colour.

 

10 DATA120,169,180,141,20,3,169,2,141,21,3,88,96
15 DATA238,192,2,173,192,2,141,26,208,76,254,233,-1
20 A=679
30 READB:IFB<>-1THENPOKEA,B:A=A+1:GOTO30

SYS679

 

Edited August 19, 2021 by carlsson

[Mazzspeed]

I could probably load this up on my 600XL, but I don't really have a need to. Just curious, can you have different color characters independent of background color on the same line just like a real C64?

[+skr]

This is software only and it uses the hardware it´s running on. You can´t even have the full Commodore characterset, only 128.

[Mazzspeed]

2 minutes ago, skr said:

This is software only and it uses the hardware it´s running on. You can´t even have the full Commodore characterset, only 128.

Ah, OK. So at this stage you couldn't make PETSCII compatible terminal software under it? Just for example.

[+skr]

The hardware stays unchanged. That said, Commodore Basic on the Atari now has access to four Pokey channels instead of three SID channels. But is there a command to control them? That would need POKEing and detailed knowledge of the hardware. Which I obviously lack, too. @8Bitjunkie unveiled the meaning of the Ataris shadow registers to me and why they can´t be used for POKEing from Commodore-Basic.

[carlsson]

Yes. Just to hammer in what several of us already pointed out: at this stage this is not a C64 emulator for your Atari. This is a C64 BASIC + Kernel operating system for your Atari. The distinction is that all memory addresses to underlying hardware are Atari.

 

Things that work:

Plain BASIC programs.

Accessing the screen matrix in its default location.

Change the screen matrix location (as seen The 8-bit Guy's video)

Using the first 128 characters in PETSCII, where fortunately the second half is inverse and generated by hardware.

Setting up own IRQ routines, making SYS calls.

Accessing Atari hardware if you know the addresses.

Partially redefining the font by overwriting the RAM where the ROM font is copied.

 

Things that won't work:

POKEs to VIC-II registers, SID and colour nybble memory

Accessing CIA registers (i.e. joysticks)

Load and save (as noted)

Possibly more advanced C64 programs that rely on the custom chips in one way or another.

Edited August 19, 2021 by carlsson

[Mazzspeed]

59 minutes ago, skr said:

The hardware stays unchanged. That said, Commodore Basic on the Atari now has access to four Pokey channels instead of three SID channels. But is there a command to control them? That would need POKEing and detailed knowledge of the hardware. Which I obviously lack, too. @8Bitjunkie unveiled the meaning of the Ataris shadow registers to me and why they can´t be used for POKEing from Commodore-Basic.

The more I read comments, the more my belief that this is nothing more than an interesting proof of concept with no real purpose is substantiated. I mean, who wants to access four Pokey channels under CBM Basic V2? What purpose would that serve?

 

I'm pretty sure even the 8 bit guy would tell you this was no more than a fun proof of concept project and no more.

 

I also never claimed the software was a Commodore emulator, I'm just trying to better understand its limitations.

[drpeter]

3 hours ago, Mazzspeed said:

... fun ....... and no more.

 

I fear you are right. I doubt it will be taking its place among the banks of 8-bit computers currently controlling nuclear power stations across the globe any time soon...

 

I am gently suggesting that 8-bit computers in general are hobbyist fun and no more, nowadays, so this is no criticism of the project. ?

 

3 hours ago, Mazzspeed said:

who wants to access four Pokey channels under CBM Basic V2?

 

Heh, heh. Presumably the same people CBM thought would like to access SID that way?   ?

 

[Mazzspeed]

6 hours ago, drpeter said:

Heh, heh. Presumably the same people CBM thought would like to access SID that way?   ?

I'm pretty sure if Commodore users wanted to create Pokey chiptunes, they'd have worked out a way to add Pokey to a C64. They wouldn't really bother to emulate a Commodore environment under an A8.

 

In the same way, I'm pretty sure A8 users don't really want CBM Basic V2.

Edited August 19, 2021 by Mazzspeed

[carlsson]

Well. I kind of find this useful - a way to get into Atari through C64 syntax. Look at my very first P/M graphic!

 

[Mazzspeed]

25 minutes ago, carlsson said:

Well. I kind of find this useful - a way to get into Atari through C64 syntax. Look at my very first P/M graphic!

 

It'd be interesting to see the same thing using Atari Basic as a comparison.

[Rybags]

It'd be virtually the same except you'd need to use a different low memory area and the program would run a bit slower.

[carlsson]

I saw that the tutorials define string variables where all data is stored, and then ANTIC is pointed to the location of the string variables. Probably this is because there are fewer holes in the Atari OS/BASIC memory map than on the C64 which has this huge 4K hole at $C000 plus small areas here and there (as you see, I'm fond of $02A7 which is 89 bytes). Actually when it comes to sprite movement, I believe Atari 64 will be quite a bit slower than original Atari BASIC but if other kinds of calculations may run faster, overall it might even out. Let's say that Atari 64 is a candidate for strategy games with more numbers to crunch, while original Atari BASIC is better for action games. Then you have those Turbo XL BASICs which probably are better for both. ? Not to mention modern dialects like FastBasic which is a serious contender for real development.

[DavidD]

Dumb question time...

 

I feel as though there are a LOT of Atari 8-bit BASIC programs out there, of all levels of usefulness and complexity... and there were TONS of Apple II BASIC programs as well.

 

Am I right in thinking that the C64 "received" fewer "high quality" programs written in BASIC?  (Possibly due to the C64 coming out later, and being more of a gaming computer than the 70's-style hobbyist computer?

 

It just seems like I've run into far more Atari and Apple software written in BASIC than I have C64, although I must admit that my C64 knowledge is limited.

[drpeter]

2 hours ago, carlsson said:

I saw that the tutorials define string variables where all data is stored, and then ANTIC is pointed to the location of the string variables.

In Atari BASIC, strings can be used for a couple of common 'hacks' to overcome the absence of routines to control sprite graphics, or even a general bulk memory move function, either in BASIC or the OS.  This is important because although sprites can be easily moved around horizontally in BASIC with a single POKE, shifting them vertically requires bulk memory moves for which Atari BASIC is too slow for most purposes.

 

Hack 1 is to hold relocatable machine language routines for bulk memory moves in strings and call them using e.g. X=USR(ADR(MOVEUP$),ADDRESSROLD, ADDRESSNEW,LENGTH)

 

Hack 2 is to take advantage of the bulk memory move functions used to reassign strings by hacking the BASIC variable table pointers so that data for some string variables is reallocated to an area of memory from which ANTIC is set to retrieve sprite data. Sprites can them be moved vertically with e.g. PLAYER0$(VPOS) = PLAYER0DATA$

 

Not sure how easily either of these hacks is possible, if at all, in CBM BASIC V2

[carlsson]

I can't recall any simple way to know the address of a variable. It probably is possible to dig out, but one also has to watch out so strings aren't moved in memory when modified. The approach I used above would be dog slow for vertical movement, in particular if you want to multiplex the player on multiple vertical positions. One probably would want to make helper routines in machine code, which reduces the usage of BASIC. But it sure is interesting to experiment with.

[Mazzspeed]

1 hour ago, DavidD said:

Dumb question time...

 

I feel as though there are a LOT of Atari 8-bit BASIC programs out there, of all levels of usefulness and complexity... and there were TONS of Apple II BASIC programs as well.

 

Am I right in thinking that the C64 "received" fewer "high quality" programs written in BASIC?  (Possibly due to the C64 coming out later, and being more of a gaming computer than the 70's-style hobbyist computer?

 

It just seems like I've run into far more Atari and Apple software written in BASIC than I have C64, although I must admit that my C64 knowledge is limited.

Basic definitely would have been more popular in the late 70's when people actually coded their own applications to achieve what they wanted, as the cost of computers began to drop throughout the 80's the popularity of Basic coding definitely declined as software companies began releasing more and more proprietary software to achieve 'mostly' better results.

 

However, I remember typing programs in from magazines and making my own applications using Basic in the early/mid 80's on the C64. But as stated, once I discovered assembly, Basic was done - It was just too slow. Just thinking of entering all those pokes and peeks as lines of data, ugh. Honestly, I wouldn't wish Basic V2 on my worst enemy - The only thing it had going for it was it was fast(ish) for Basic, which was still Dog slow.

 

Sure, assembly language involves more work for a given task, but the increase in speed and flexibility made it so worthwhile. Furthermore, you have to remember that by avoiding Basic you could bank almost all 64k clear on the C64 making space to achieve so much more than you would under only ~38k of memory, it was this memory flexibility that allowed the C64 to do so much without the need for ram expansions.

Edited August 20, 2021 by Mazzspeed

[drpeter]

1 hour ago, carlsson said:

strings aren't moved in memory when modified.

I think in MS BASICs (of which CBM V2 is a dialect) string data memory is dynamically reallocated during program execution, something that doesn't happen with Atari BASIC- allowing Hack2 above to be easily implemented with safety.

[Mazzspeed]

17 minutes ago, drpeter said:

I think in MS BASICs (of which CBM V2 is a dialect) string data memory is dynamically reallocated during program execution, something that doesn't happen with Atari BASIC- allowing Hack2 above to be easily implemented with safety.

If Commodore still existed today, I'd actually wanna high five someone there for the way they screwed Microsoft on that licensing deal. It was like Karma, just backwards...

[carlsson]

@drpeter Exactly how I remember it too. Directly following the listing, all variables are listed with type, length and start position. Strings then are stored from top of memory and working backwards as more strings are added or concatenated. While it would be possible to dig out the current position of a variable, it would be rather cumbersome.

 

Now I got this bizarre idea to write a C64 BASIC extension that has keywords to handle Atari custom hardware...

 

[Rybags]

There were some PET Basic programs that would have been popular at the time and practically port straight up to the C64.

 

Strings - the stock MS type Basic usually has the LEFT/MID/RIGHT$ functions for what they're worth but have the annoying limitation of 256 character limit, usually not easy to find the address (sometimes stored backwards from top of RAM), and doing insertions usually somewhat harder than with Atari Basic.

[carlsson]

34 minutes ago, Rybags said:

the annoying limitation of 256 character limit

Eek! I had completely overlooked this. I suppose MISSILE$, PLAYER1$ etc would be possible to keep in strings but the 384 byte BUFFER$ would not be possible to keep in that form in Commodore BASIC anyway.

[Rybags]

Really you have to ask yourself why bother developing Atari hardware dependent games with this given we have numerous alternatives already.

[carlsson]

I think it belongs in the same category as why would anyone write programs in BrainF*** when there are much better programming languages.