Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ivop

Members
 View Profile  See their activity

  • Content Count

    2,282

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by ivop

  1. Posted

    Although I still don't have a v1.02 MAC/65 dump at my disposal, I investigated how it (and Action, Basic XL,XE) can be converted to a SIC! cart.

     

    OSS carts use the address lines to do bank-switching, i.e. write something to $d500, $d501 or $d509 selects a different 4k bank at $a000-$afff ($b000-$bfff is a fixed bank)

     

    SIC on the other hand uses the databus to do bank-switching, i.e. write $00, $01, $02, etc... to $d500. It can disable $8000-$9fff (which is off by default) so the amount of free RAM will be the same.

     

    All of the above mentioned OSS carts use single store instructions to switch banks, which leaves all registers (A,X,Y) unchanged. Switching to a different SIC bank needs something like PHA, LDA #$02, STA $D500, PLA, which does not fit in the same space, so it should be put in a subroutine (jsr foo fits in place of sta foo). Sadly, there is no free ROM space in bank M to put three such routines, so that only leaves RAM. My idea is to use SIC bank0 to setup the switching routines at, let's say the bottom of the stack, then switch to bank 1 and run the cart which has all bank switching stores replaced by the corresponding jsr's.

     

    OSS carts:

Physical order of banks: M, 0, 9, 1.

A3 A0 A000-AFFF B000-BFFF RD5	 Values
0 0 bank 0	 bank m	 1	 0,2,4,6	 $d500
0 1 bank 1	 bank m	 1	 1,3,5,7	 $d501
1 0 off		 off		 0	 8,A,C,E
1 1 bank 9	 bank m	 1	 9,B,D,F	 $d509

     

    SIC! Cart:

Each bank is 16k

$00 bank 0:	 8k off	 8k init code, copy bankswitching code to bottom of stack, switch to $01 and run
$01 bank 1:	 8k off	 4k oss bank 0, 4k oss bank m
$02 bank 2:	 8k off	 4k oss bank 1, 4k oss bank m
$03 bank 3:	 8k off	 4k oss bank 9, 4k oss bank m

shortest code I can come up with: (18 bytes)

switch01:
pha
lda #$01
bpl switch
switch02:
pha
lda #$02
bpl switch
switch03:
pha
lda #$03
switch:
sta $d500
pla
rts

     

    If this works, you can also put a menu in bank $00 (plenty of space) and select one of four carts and fill 4-6, 7-9 and 10-12 with the other three M019 OSS carts and run one of those instead :)

     

    ATM I am busy with other stuff and I don't want to do too many things at once, but this should get you or anybody else started in porting these carts to a sic cart.

  3. Posted

    Perhaps we should start a thread for these? (i.e. games, utilities that do not work out of the box with a sic! cart)

     

    Here's and .xex file which contains DOS 2.5 + Atmas II which can be used to boot both at once from a SIC! Cart.

     

    This file can also be used to boot from several emulators (boot file/image) and other $700 based boot loaders. Aspeqt file loader works as well. DOS is loaded at $5700 and moved to $700 before initializing DOS and running the application, atmas 2 in this case.

    atmas.xex

  6. Posted

    I agree on level codes. I am playing on real hardware, too. Continuity saves its state in a cookie (I had to turn them on for that particular domain though ;) ). As for the rest, if the music bothers you, turn the volume down. If you can't find the right transition between screens, look harder! :) Or perhaps you cannot leave the screen at that side at all. Happens in Continuity and I have seen it in RR already. That's the whole point of the puzzles. Which leads me to the puzzles. As there's is no time limit and unlimited lives, it's not really an arcade game, but a logic game. That's why I got really frustrated when I had solved the puzzle, but didn't advance to the next level for over 10 minutes because the way to solve it needed to be pixel perfect. Still, it's a great game IMHO. A remarkable piece of programming!

  15. Posted · Edited by ivop

    Do not forget that the amount of data to be processed has also increased enormously. A single cycle faster per pixel faster in assembly can mean the difference between being able to play a H264 encoded video on your hardware or not being able to. Look at FFmpeg (a cross-platform multimedia project), there's still a lot of assembly code in there for the speed criticical stuff.

    Also, for a long while, most compilers did not take any advantage of SIMD instructions.

     

    As for 8-bit c-compilers, IMHO the biggest mistake is to switch to a "simulated" stack. Just use the CPU's stack for return addresses, make function variables static (i.e. fixed memory addresses, not on the stack) and forget about recursion. Most of the time, you don't need it, and if you do, program around the compiler's limitation. The resulting code will be way faster than sdcc, cc65, etc...

    • Like 2

  18. Posted

    Here's a patch with some fixes for Linux and g++ (warnings, deprecated stuff, etc...) and an updated Makefile. One can now do a normal build (make), a profile generate build (make pg) and after running the rastaconv-pg binary for a while, one can make a profile-use build (make pu). The resulting rastaconv-pu binary should be faster :)

    ivop.patch.zip

  19. Posted

    I tried getting the Qt Libraries on my computer. didn't work

     

    I don't have a Mac running Mac OS X at the moment, but it should be possible to get this to work with MacPorts and the Qt libraries. Perhaps you can get one of the Aspeqt devs to (cross)-compile a (static?) binary or work together to get the problems you experience resolved?

  20. Posted · Edited by ivop

    Yeah, tape takes ages. But I have fond memories of waiting 15 minutes for Boulder Dash to load from tape, fail once, reload and after about 35 minutes we had the game running. And this was a special day, mostly sundays, on which we took the Atari downstairs to our colour TV (on week days, my brother and I played games in black and white on our old TV upstairs). If you really want to relive the old days, press play on tape ;)

     

    edit: oh, and Boulder Dash was worth the wait and still is :)

    • Like 1

  24. Posted · Edited by ivop

    I think the fastest is still to use a 512-byte look-up table, if you can sacrifice the memory.

     

    ldx 128		 ; 3
lda lsbtab,x ; 4, tables must be page-aligned
sta 129		 ; 3
lda msbtab,x ; 4
sta 130		 ; 3
	    ; += 17

     

    If, as you say, bit 7 of the value in 128 is for other use and should not be part of the calculation, you do not even need to mask it out before using it as an index. Just ignore it when calculating the tables. If you do mask it out before you use it as an index (lda 128, and #127, tax) you can reduce the tables to 128 bytes each.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...