Wrathchild
-
Content Count
2,924 -
Joined
-
Last visited
Posts posted by Wrathchild
-
-
Thanks for the tip. AR doesn't use any of the OS
and provides its own interrupt handler routines.
So I have a high percentage good feeling that just
the LDA $FF, STA $D301 will suffice in this case.
-
Yep, that icon was me with the hat on
. So d) is fixed.(it wasn't a typo - that's what I had coded
)As a by product of working on b) I seem to have fixed a)
:!: 
And if that's confirmed that the original game only played those
2 bars of music then I'll consider c) closed too.
Therefore only b) to complete - you lucky people :!:
I'm toying with redirecting the display list, so that the DLIs don't trigger.
If I can't get that to work then turning off the display altogether maybe
the only solution. This causes some flickering though when multiple
little files are loaded but might be avoidable with some delays, e.g.
wait until a certain scanline. Otherwise this may just be something we
have to life with. From what I have seen already, we'd be losing out on
the messages like 'Entering...', 'Leaving...' etc whilst the loading is done,
but as this is much quicker now its not too much of a loss.
So maybe it could be another Thursday night release again
Take care,
Mark
-
Isn't PORTB $D301 instead of $D302?It was me getting that wrong...
It was after midnight after all
Cheers,
Mark
-
Ah, forgot to add:
d) Still to fix the 'Disable Basic' crashing on XL/XE machines.
This is even after setting $D302 during the cart initialization and
maybe down to something else. I need to debug this a bit further.
-
Stage 2 is almost upon there...
Had a bit of a breakthough today... two more similar (but in
different memory areas) loading routines were reworked in
order to get the replacement 'get sector' routines working.
Hopefully that's it for now.
One thing I had to do was to take out a call which re-writes the
read and decoded sector back to the disk after re-encoding it.
Not sure of the purpose of this but it appears to be OK without
it at the moment, though it may be linked with a) below.
So, I can setup a temporary character and have them walk around
the city and have encounters. However, the following is still to do:
a) When entering buildings the system automatically leaves them.
Identifying the cause of this may take some time to track down.
b) The main game screen is using DLIs who's code is located in
the cart area. Therefore during simulated disk (i.e. now cart)
access the screen is temporarily corrupting. I've tried disabling
interrupts but as the execution window for the copying is very small,
'off' before getting a sector and 'on' again when it's finished, the
perceived display corruption is still there. Some more work is
therefore needed to tidy this up.
c) One thing I noticed in the cart and cracked versions, but I need to
get my A8 out to test on real hardware, is that after pressing 't' for the
temporary character, the gate screen appears and music starts, but
when the P/M bars finish opening to reveal the gate and the force-field
starts, the music stops? Seems odd to me.
So, if a solution to b) can be made I could be in a position to release
Stage 2 later this week, though it would be nice to get a) done as well.
Hang in there!
Regards,
Mark
-
Silly me, as most development is done in A800WinPlus I had started
using my normal 64K 800XL, but I switched to the 48K OS-B to develop
against, therefore this wasn't an issue. I'll get that patched up for the next build.
@eobet, yes indeed - and this game is quite worthy of this reputation!
I'm now getting into the standard routines for loading game data from
the last 3 sides, i.e those only taking 120 bytes of data from each sector,
the others being part of the encryption. The aim is to leave these 'as-is'
and let the existing code (albeit modified by Glenn) do the work.
The thing I'm worried about is the reported occasional writes to one
of the game disk, this may require a re-think...
Regards,
Mark
-
Thanks for the report.
This seems odd behaviour as the OS would have already detected
the presence of a cart during powerup and so basic should be in.
It maybe a by product of some of the AR booting code - I'll check.
Perhaps Steve can comment on if this is a 103XE specific thing?
Regards,
Mark
-
Great demos Michal! Kind-of an 'Aladdin'/'Prince of Persia' feel to it.
My 2-cents on the main Cart models:
XEGS : Maybe good for your size of game.
With this you get the last bank of the cart always in the range $A000->$BFFF.
I like this as it gives you a fixed base for all your core-routines.
Bank access occurs by selecting your 8K bank to sit $8000 an $9FFF.
So this can be used for copying out graphics etc, access music temporarily etc.
Because you can fix code in the swapable banks, this frees up the memory
(typically $0600->$7FFF, though you can go lower) for display memory,
game variables etc. I think the advantage of this is that you can make
large games that can run in 32K and even 16K, e.g. on a stock 400 or 600XL!
Finally, this has an advantage in that you can re-use existing XEGS carts
quite easily by replacing the (E)PROMs.
Switchable XEGS:
As above, but has the advantage of being disabled - freeing up the memory
underneath. A bit more thought needed when developing on this but very nice.
I don't think there are standard boards for these in existing commercial titles,
the mod'd boards are done by Nir Dary.
MultiCart:
Similar to the Switchable XEGS except that a whole 16K is selected between
the range $8000 and $BFFF. I find this slightly less easier to work with than
the XEGS, but each to their own I guess. Typically I'd relocate a bank-selection
or disable routine to the working RAM and then any code can access it safely.
These boards are made by [email protected] and, though I haven't got one,
have a professional look to them.
FlashCarts:
Made by Steve/Classics @ AtariMax - available in 128KB and 1MB sizes.
These use a single 8K bank between $A000 and $BFFF and can be disabled
to acces the RAM below. So, again, some thought is required when planning
the swapping, but some more RAM is free'd up (on machines >32K) between
$8000 and $9FFF. As pointed out elsewhere, these have the re-usability factor.
Also, though yet to dive into this myself yet (soon though...), you can include
code in your program to erase and write to banks (64K each in size) within
the flash mem. Therefore high scores/game states/player data etc can be
saved and recalled without the need for a tape/disk drive.
Hope this summary helps people - feel free to correct any inaccuracies.
Regards,
Mark
-
Stage 1 has been reached!!!
And its been painful getting there :!: If it wasn't for half the cracking already done by the mysterious
'Glenn' then this would have taken a lot longer I can tell you!
There are so many replacement loading routines they'll be
in the double figures before too long.
OK - so what does this do?
Using a real machine and an 8Mb flashcart -
or an emulator supporting it:
You can run the intro right through and press START at any time to
continue loading. I was able to relocate the P/M memory used for the
loading-tracker and so this still appears, albeit running a little faster.
You then see the Character option screen. Ignore all the disk based
stuff for now - press 'T' for a temporary character. Enter and verify
your name and then select your stats at the Gate by pressing 'Space'.
You will then be Joined...
After which a crash occurs
Don't worry about this, that's how far I wanted to get for this release.
I'll be having a little break before commencing with the next release,
wife not too happy at me coding 'til 2am and a short holiday coming up,
so be happy with the great progress so far for now.
(1 weeks work!)The aim of the next release will be to get the game working with the
temporary character. The following release should then look at adding
the disk or flashcart loading/saving support. I've gone back to favouring
the flashcart as, because the disk I/O functions have been over-written,
these would have to be re-replaced whilst the load/save to the character
disk is done and then replacement ones replaced - confusing huh
Also, the O/S disk I/O routines cannot be used as the memory areas
they would use are no longer available. Again, we'll have to wait and see.
Best wishes,
Mark
PS: I'm not 100% certain that my replacement Get-Sector-From-Rom
routines are fully protected from interrupts occuring whilst a ROM bank
is switched in, but it seems to be OK.
-
Interesting stuff, I'll look into this whilst doing the cart port. Maybe it
could be possible to get the game to adjust itself if a PAL system
is detected. Anyone have some common code for this?
Certainly the intro music sounds better in NTSC mode!
Regards,
Mark
-
So the aim for next week will be to have the first cart image ready from which the intro will run and then allow a character to be created.Objective almost complete, remaining is:
After the intro, the loader uses PMs to display its countdown - an neat base 6 ticker. This is using the memory $BC00->$BFFF. Because the Flash cart swaps in and out whilst transfering memory blocks, this looks corrupted. The 2 solutions to this are 1) don't display anything, which isn't too bad a substitute and 2) Remap the PMs somewhere else. This should be OK as the loader doesn't use anything between $1C00 and $1FFF and so they can go here. Therefore I'll go for 2) and if it works out to hard I'll do 1).
Next - after the main game code is kicked off - there are a few more sector accesses from Disk 1 - Side 1. haven't check what for yet, but they need to be reproduced. The pain in the ass is that once the game code has been loaded, the I/O routines are in a completely new place and so I must write a replacement for them.
Question - does anyone know if D1S1 is ever accessed again?
Regards,
Mark
-
Hi,
I've disassembled and gone through the intro and character creation code.
This looks straight forward enough to simply lift the memory post its loading
but just prior to its execution from within the emulator so that these can be
loaded directly from flash and then jump'd to, rather than re-writing the
disk-access routines for them. That will get me to the stage of then looking
at the 'Insert disk X/side Y' code so that I can then formulate how that can
be remapped to Cart.
From what I've seen so far - AR uses replacement Disk I/O routines in a
similar way to LucasArts 'Koronis Rift' and 'The Eidolon'. Therefore replacing
these shouldn't be too tricky, except all RAM ($480->$BFFF) seems to be in
use so it looks like the new routines will have to replace over the existing
routines, i.e. be written at/over the same memory locations.
Any other bits at pieces (like the copy protection) will hopefully
fall out as I come across them, and I can explain them later.
So the aim for next week will be to have the first cart image ready
from which the intro will run and then allow a character to be created.
With regards to the character disk - I think it maybe worthwhile keeping
it disk based for the early work. The logic here is that there is quite a
lot of menuing/code related to this that will be best left-alone for now.
I tend to go for a temporary character at the moment anyway
Regards,
Mark
Questions: The disk request routines appear to be able to ask for all
of the 'other' titles, 'Dungeon', 'Arena', etc. Does anyone know if the
game engines are identical/very similar and are the character disks
interchangeable between the City and Dungeon?
-
I had already started work on a cart version of "Winter Olympiad 88"
but seems like there's more call for these two games, so I can
switch to work on these if it doesn't conflict with anyone else trying
the same thing ?
I have an original AR-City but no Dungeon - so with regards to
the copy protection, I guess the basis for this work will be the
cracked disk images included with the XLit emulator?
The re-write should also permit the saving of characters to the
flash cart - so the feasibility of this will also have to be investigated.
City or Dungeon first? Well, let do them in order of appearence.
Hopefully after doing one the other should follow easily.
There may also be just enough space on an 8Mb flash cart for both games.
Regards,
Mark
-
Not the impression I got, but 'I cant get to see the file through atari dos' isn't too clear
Carmel, can you post the related, binaries/atrs you are using and exact steps of what you are doing and what you expect to see but are not?
All: Would it be worth trying to convert the PC util Exomizer for the C64 to produce A8 files?
Regards,
Mark
-
If you're using windows then there's the MakeATR program.
You can transfer files in and out of an ATR image that's been formatted with DOS.
-
It's already been done with the 1Mb Flash cart by Steve.
Check the Forums at www.atarimax.com
-
Hi,
I'll be coming along to this event for the first time,
so I'm interested to know if any other Atariage members
are heading there too.
Best wishes,
Mark
-
Thanks alot, I was only using Vice 1.4, upgrading to 1.16 certainly helps!
-
Is there a Commodore 64 emulator with a monitor that can allow you to trace execution and output the tracing to a file, e.g. Program counter, instruction and register states?
Ah, should add that I'd need a Windows based one.
Thanks,
Mark
-
nice to see your back with the A8, what ever happened to your elite game...I never went away
Search around these boards for info on Elite's lack of progress... certainly won't be resurrected in the near future PM me for any further followup. Best wishes, Mark
-
Similar here, the first UsbTest disk didn't detect these devices, but the latest one does. I also have a little IrDA device but as the function of that is limited against an Ethernet device, I'll not concentrate on that.
What's nice about these devices is that, I think, you can use a small transfer buffer between the device and your driver software, e.g 8 bytes. Saying that though, making the driver work through the OS's I/O routines/handlers would be desirable.
General Question: Has any work been done to make CC65 libraries (in 'C',ASM or a mix) for use with the USB cart?
Regards,
Mark
-
Great idea, anything to do with the Contiki/uIP work done so far?
I have a USB cart and would like to turn my hand to a driver for
those cheap USB to Ethernet adaptors, but a few other bits to do first
Best Wishes,
Mark
-
For any aspiring ROM makers, this may help a bit. Primarily it highlights the differences in the XEGS, MegaCart and Flash Cartridge models but also shows a way of using CC65's powerful assembler and linker to easily construct ROM images. Ask any questions about it can be posted on this topic and I'll try to help as much as possible to describe how/why things were done.
Also it gives away a nice little simple Run-Length-Encoder that I knocked up in Java to ensure that blocks don't span cartridge page boundries. The decompression code is in the routine 'load_data_file'.
Ultimately the three separate source files are common enough so that one version containing #ifdef statements to control what is included based upon the selected cartridge model could have been developed, if someone would like to do that and show me how the makefile could be used to build all 3 I'd be grateful, mine seems to rebuild the ROMs even when the object file hasn't changed.
Regards,
Mark
-
1
-
-
It looks to be a bug in the 3.1+ code. After having switched out the ROM, when you write to $D500 to switch it on again, the SWXEGS model only sets the bank at $8000->$9FFF and doesn't re-enable the last bank of the ROM to $A000->$BFFF properly, hence a jump to routine there was hitting a BRK command and the system goes potty.
However, I did have the issue you saw occur in my 4.0+ so I'm re-posting my current image just in case.
Regards,
Mark
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
AR: City - FlashCart / Stage 2
in Atari 8-Bit Computers
Posted · Edited by Wrathchild
A day earlier than expected
Here is Stage 2. Remember the goal for this release was
to permit a temporary character to roam around the city
and do the sort of things any respectful (or disrespectful
for that matter) AR character would want to do...
Well you can now!
The solution to avoiding the DLIs was to defer the data
transfer from ROM to the disk I/O buffer to between certain
scan lines. Just to be annoying I've added some code to set
the background colour to the read byte value during copying.
This will be taken out in the full release, though may remain
as a single flashing line in the lower part of the screen, just
to indicate that the system is busy.
I anticipate some bug reports (use this thread), e.g. I have
still had 'leaving' issues when entering some buildings
(An Inn, maybe this happens if they're closed?).
Still, enjoy this release and be patient whilst I try to now
support either disk or flash loading and saving. Its early days,
but the 'image' for the full version won't be released.
As I've already freely put out the cart conversions of:
The Eidolon, Koronis Rift and Gauntlet - I feel its time for
some payback on the effort put in. So I'll most likely be
working with [email protected] in having AR produced.
As some people may already have 8Mb FlashCarts and may
not want to part with hard-earned cash for another one.
In that case it could be possible to setup something else,
e.g. pay by PayPal and receive the image by email.
Perhaps it could be free and people simply make volentary
payments to me in recognition of my efforts?
Undoubtedly, pirating will out itself and the image will be
passed around for all to use, lessening my resolve to make
more images in the future.
Please post your thoughts on what to do with the final release.
Best wishes,
Mark
Ar_cart_v2.zip