Back in the day I learnt a lot from reading these articles and code. It gave me the confidence to make games. I have now been fortunate enough to experience a thirty year career making games. I currently work on the COD franchise.
@@stephenwhite506 Nice, I wonder how many others got their start with these articles. I have a very similar story and now also make video games for my day job. I thought it would be nice to revisit these articles now and see what was good and what wasn't and how much I can remember about working with the Amiga and the 68000
The screen scrambling is because AGA double-CAS fetch mode is enabled. When shutting down an AGA Intuition screen and switching to a custom copper list, the new list needs to set fetch mode to zero. Since OCS games don't know about fmode and it's troublesome to update all custom copper lists, you can fake it by clearing the fmode register after the custom vertical refresh vector has been reassigned. Somewhere after TakeSystem returns, you need to add: "move.w #0,fmode(a6)" or if your includes are old: "move.w #0,$dff1fc" When returning to Workbench, the system copper list will restore fmode, so the original value doesn't need to be saved.
You have predicted part of the next episode, although I didn't quite solve it the way you said above, but I was pretty sure the shutdown was not correct for newer Amiga, but I wasn't exactly sure why. I think my plan is to convert this game to work as AGA anyway as we already have a working OCS/ECS version (and the source code doesn't have the complete data for the whole game anyway, so it would need to have other levels, music, titles and sound reconstructed).
@@DavePoo2The fmode is first port of call to make aga system to ecs/ocs. Also ks issues. 2nd port is.68020 problems.in code. Disable cache first and then look for.trouble.some.code. plenty of guides
@@easyerthanyouthink The idea here isn't to downgrade the machine to OCS or ECS standard to get it to work, but to upgrade the game to work on AGA or anything that we want.
Good stuff! I remember reading Dave Jones Locker in Amiga Format. But I only played the level and stared blankly at the assembly code. Remember he was doing clever stuff with hardware sprite collision and run length encoding on the end of level boss.
I did a lot of studying of it back in the day, but have forgotten most of what I know about it. I did start writing a platform game on my A600 and got it going to the point where i had a main sprite background tiles, but I didn't get much further. I'm starting to get more familiar again with 68000 machine code. I think it was a really good set of articles from Amiga Format and still today a little surprised that a publisher would allow the source of their game to be given away.
Wow, this takes me back to those long DevPac days and nights of 1989! Indeed, the games I wrote for Amiga did take over the hardware and ended up breaking on a faster system. I even wrote custom floppy disk read/write because there was lots of reading to do while DOS was inactive. Maybe someday someone will unearth the source code for the games I wrote back in the day, which have quite a few clever ideas and implementations.
You did! And it was so easy to create code that wouldn't work on a future system. It would have been better if Commodore had laid out a system takeover that everyone could use. But I suppose they maybe didn't want you to take over the hardware and rather you use the OS calls to get everything done. You should unearth the source code and get it in Git or something, my plan is to at least resurrect this Amiga Format code and get it working properly on later Amigas, it's a shame more of the source for these old games isn't out there and preserved so we can update and change them. DOOM is a prime example of open source working so well, that game went open source and still today it runs on every platform in the universe thanks to all the porting and updating.
A file starting with ":" means it is located at the root of the partition. Use "incdir" to tell where your include directory is and strip away the ":" characters if you don't want to type the full path - the source was probably set up to work directly from the floppy from the magazine. Display fix: Loadview(Null); WaitTOF(); WaitTOF();
@@DavePoo2 Have you looked at the "HowToCode" writeups? They contain many years of distilled wisdom from demo coders on how to do takeover and giveback (plus much more).
@@byteforever7829 it is, but unfortunately the next episode will be on emulator as I don't have access to my Amiga right now. It's actually easier on the real machine as the keyboard mapping from pc to Amiga is a little strange. (Like the right Amiga key is mapped to Home)
@DavePoo2 thank you for adding the link. For an A1200 trying to run this code without modification it might be possible to reset the hardware registers to a "like A500" compatibility state then call into this code. A bit like the NoFastMem utility.
If I'm guessing correctly, fast: is (usually) a HD formatted to use the "new" fast file system, which was (again IIRC) not compatible with the older, "slow" file system. You'd need a mountlist entry and, sadly, I'm no longer any good with those. ;)
True, but it has been slighty useful in debugging the takeover code as it works right up until the system takeover truely happens. Also, the Amiga Format article mentions that it's possible debug one system with another in DevPac via a parallel link, no idea if that is actually possible, but I'd like to look into that.
@@DavePoo2 I remember an Amiga feature called ROMWack that allowed you to connect via serial terminal @ 9600 8N1; I tried it very briefly in 1997 but didn't do much with it.
I was considering porting this to a more modern system, but I don't know 68k assembly. Do you have any resources you'd recommend, either for learning it or tools to just outright translate it into a higher level language? I guess I'll look for the processor manuals either way. Hopefully it's not too far off from z80 or 6502 assembly.
@@anon_y_mousse not sure, it's been absolutely ages since I did any 68000. I think 68000 is easier than 6502 thanks to the larger number of registers and it has multiply and divide instructions (fancy). I think one you know how to move memory and branch, you have figured out a lot.
After programming the 6502 or the 68000, the x86 assembly code of old was such a mess to look at. It's still a big messy now with all those legacy register names going EAX etc. Well, we have C and C++ now so we don't have to look at it too much.
I was all Z80 until 1990 when I got an Amiga, then a lot of 680x0. After getting a 486 DX33 (for Doom :), I started doing some 32 bit x86 coding (I haven't done any 16 bit x86 - it's nasty!) With each PC upgrade, I have done more: MMX, SSE, SSE2, AVX, AVX2. I am still using my 12-year-old X79 (initially 6-core i7, now 12-core xeon) which beats the $#!+ out of the Windows 11 'supported' Celeron!. So there is no point e-wasting this perfectly good system just to make M$ and PC retailers happy!
@@MrJozza65 Yes, and the code is from 1988, so this is basically kickstart 1.3 days. In theory code written for that Amiga should work on all of them, but I have no idea if Commodore set out those guidelines anywhere. This code even pre dates the Amiga 500+, and I can see things in the start-up code that might fail on a 68010 processor.
Back in the day I learnt a lot from reading these articles and code. It gave me the confidence to make games. I have now been fortunate enough to experience a thirty year career making games. I currently work on the COD franchise.
@@stephenwhite506 Nice, I wonder how many others got their start with these articles. I have a very similar story and now also make video games for my day job. I thought it would be nice to revisit these articles now and see what was good and what wasn't and how much I can remember about working with the Amiga and the 68000
The screen scrambling is because AGA double-CAS fetch mode is enabled. When shutting down an AGA Intuition screen and switching to a custom copper list, the new list needs to set fetch mode to zero. Since OCS games don't know about fmode and it's troublesome to update all custom copper lists, you can fake it by clearing the fmode register after the custom vertical refresh vector has been reassigned.
Somewhere after TakeSystem returns, you need to add: "move.w #0,fmode(a6)"
or if your includes are old: "move.w #0,$dff1fc"
When returning to Workbench, the system copper list will restore fmode, so the original value doesn't need to be saved.
I'm impressed people with this arcane knowledge are still around and can still remember the hardware register addresses.
You have predicted part of the next episode, although I didn't quite solve it the way you said above, but I was pretty sure the shutdown was not correct for newer Amiga, but I wasn't exactly sure why. I think my plan is to convert this game to work as AGA anyway as we already have a working OCS/ECS version (and the source code doesn't have the complete data for the whole game anyway, so it would need to have other levels, music, titles and sound reconstructed).
@@DavePoo2The fmode is first port of call to make aga system to ecs/ocs.
Also ks issues.
2nd port is.68020 problems.in code. Disable cache first and then look for.trouble.some.code. plenty of guides
@@easyerthanyouthink The idea here isn't to downgrade the machine to OCS or ECS standard to get it to work, but to upgrade the game to work on AGA or anything that we want.
@@DavePoo2 ok thx
Good stuff! I remember reading Dave Jones Locker in Amiga Format. But I only played the level and stared blankly at the assembly code. Remember he was doing clever stuff with hardware sprite collision and run length encoding on the end of level boss.
I did a lot of studying of it back in the day, but have forgotten most of what I know about it. I did start writing a platform game on my A600 and got it going to the point where i had a main sprite background tiles, but I didn't get much further. I'm starting to get more familiar again with 68000 machine code. I think it was a really good set of articles from Amiga Format and still today a little surprised that a publisher would allow the source of their game to be given away.
Wow, this takes me back to those long DevPac days and nights of 1989! Indeed, the games I wrote for Amiga did take over the hardware and ended up breaking on a faster system. I even wrote custom floppy disk read/write because there was lots of reading to do while DOS was inactive. Maybe someday someone will unearth the source code for the games I wrote back in the day, which have quite a few clever ideas and implementations.
You did! And it was so easy to create code that wouldn't work on a future system. It would have been better if Commodore had laid out a system takeover that everyone could use. But I suppose they maybe didn't want you to take over the hardware and rather you use the OS calls to get everything done. You should unearth the source code and get it in Git or something, my plan is to at least resurrect this Amiga Format code and get it working properly on later Amigas, it's a shame more of the source for these old games isn't out there and preserved so we can update and change them. DOOM is a prime example of open source working so well, that game went open source and still today it runs on every platform in the universe thanks to all the porting and updating.
Which games did you write for the Amiga?
@@borchen0 ua-cam.com/users/liveiX0WRYTYVp4?si=RAThjsvnJ_IlCNaf Excellent 👌
Good a'ternoon, Dave.
I will dedicate Barnsley FC's victory today in the football to your Menace double-header (assuming they win, that is).
And just as I say that they go and play the worst 10 minutes I've ever seen and go 2 goals down
@@thegreathadoken6808 I have no clue what you are talking about. Probably football ⚽
@@DavePoo2 The other team played Football. I don't know what Barnsley were doing.
A file starting with ":" means it is located at the root of the partition. Use "incdir" to tell where your include directory is and strip away the ":" characters if you don't want to type the full path - the source was probably set up to work directly from the floppy from the magazine. Display fix: Loadview(Null); WaitTOF(); WaitTOF();
Thanks. Your suggested fix has predicted some of the next episode. Although it wasn't all that easy for me.
@@DavePoo2 Have you looked at the "HowToCode" writeups? They contain many years of distilled wisdom from demo coders on how to do takeover and giveback (plus much more).
@@NorthWay_no I've not heard of those. I've got the bare metal Oostercamp book for reference.
there was a notice at the end that said if compiling from coverdisk, add the path 'CoverDisk#08:DaveJones/'
@@bazza5699 Compilation straight from floppy, now that IS old school indeed.
So cool doing this on the real hardware😀
@@byteforever7829 it is, but unfortunately the next episode will be on emulator as I don't have access to my Amiga right now. It's actually easier on the real machine as the keyboard mapping from pc to Amiga is a little strange. (Like the right Amiga key is mapped to Home)
When I looked at assembling this source code in my latest video I deliberately kept it to an A500 for compatibility.
Yeah, it works on A500 no problem. But then this code was from the "A500 days"
And here is the link to your video if anyone is interested ua-cam.com/video/_YefsDKE3i0/v-deo.htmlsi=kJOiyeIRrQSmorbh
@DavePoo2 thank you for adding the link. For an A1200 trying to run this code without modification it might be possible to reset the hardware registers to a "like A500" compatibility state then call into this code. A bit like the NoFastMem utility.
@@MartinPiper6502 Thanks 👍. I've already had some success and that will be in the next episode.
Hopefully I'll get the chance to try this one day...
I'll be putting the what I've been doing on git soon enough so we can all have a go.
If I'm guessing correctly, fast: is (usually) a HD formatted to use the "new" fast file system, which was (again IIRC) not compatible with the older, "slow" file system. You'd need a mountlist entry and, sadly, I'm no longer any good with those. ;)
@@jamesf9829 I just got rid of that path and included my own Amiga headers in the devpac settings. More in the next video.
You can't debug code that takes over the system; The debugger uses the system! :)
True, but it has been slighty useful in debugging the takeover code as it works right up until the system takeover truely happens. Also, the Amiga Format article mentions that it's possible debug one system with another in DevPac via a parallel link, no idea if that is actually possible, but I'd like to look into that.
@@DavePoo2 I remember an Amiga feature called ROMWack that allowed you to connect via serial terminal @ 9600 8N1; I tried it very briefly in 1997 but didn't do much with it.
I was considering porting this to a more modern system, but I don't know 68k assembly. Do you have any resources you'd recommend, either for learning it or tools to just outright translate it into a higher level language? I guess I'll look for the processor manuals either way. Hopefully it's not too far off from z80 or 6502 assembly.
@@anon_y_mousse not sure, it's been absolutely ages since I did any 68000. I think 68000 is easier than 6502 thanks to the larger number of registers and it has multiply and divide instructions (fancy). I think one you know how to move memory and branch, you have figured out a lot.
It would be interesting to check if the binary runs on a 500
@@vertigoz that will be in the next video
I think same.
I began assembly on C64 and then i switched to intel 80286 with MS DOS. I never tried to attack a library.😂
After programming the 6502 or the 68000, the x86 assembly code of old was such a mess to look at. It's still a big messy now with all those legacy register names going EAX etc. Well, we have C and C++ now so we don't have to look at it too much.
I was all Z80 until 1990 when I got an Amiga, then a lot of 680x0.
After getting a 486 DX33 (for Doom :), I started doing some 32 bit x86 coding (I haven't done any 16 bit x86 - it's nasty!)
With each PC upgrade, I have done more: MMX, SSE, SSE2, AVX, AVX2.
I am still using my 12-year-old X79 (initially 6-core i7, now 12-core xeon) which beats the $#!+ out of the Windows 11 'supported' Celeron!.
So there is no point e-wasting this perfectly good system just to make M$ and PC retailers happy!
Interesting stuff. Was the A1200 out when Amiga Format published these articles, or did it come out later?
Ah, just answered my own question, the A1200 came out in 1992 and this was from 1990 🙂
@@MrJozza65 Yes, and the code is from 1988, so this is basically kickstart 1.3 days. In theory code written for that Amiga should work on all of them, but I have no idea if Commodore set out those guidelines anywhere. This code even pre dates the Amiga 500+, and I can see things in the start-up code that might fail on a 68010 processor.
@@DavePoo2 For AGA chipset the system takeover code has a little bit more to do than what was required for A500