Did you like Barbarian from Palace Software?
But were you disappointed about the CPC-"limitations"?
For me, the most annoying limiatation was, that you have to select a scene on startup.
So I begun fiddling on a 128k version of the game, which pre-loads all 4 scenes, and checks, which opponent is actually fighting.
For this I disassembled the game, and patched a CALL xxxx to jump to my routine(s) instead of the old CALL.
In the routine I check:
- Store the required registers
- Actual opponent number (0-7)
- Select background scene for actual opponent (You have 8 opponents, and 4 backgrounds, so the result is: every 2nd opponent the background changes)
- Fix background's palette (Scene 1 has a slight different palette than scene 2,3 and 4)
- Write HUD (Scores, "MODE" message and the red life-points) into buffered background
- Write some variables from unseen screen ram into buffered background
- Write area of buffer background into the game's doublebuffer
- Bring buffered background to front
- Restore the registers
- CALL the original address (which should be called in the original CALL I replaced)
Most problematic here:
- I had to split the code: A part is before the original gamecode, and the other after the original gamecode
- Very limited memory space (The game stores variables etc... almost everywhere in ram)
- The routine is a bit slow, so the music stucks a little. Perhaps someone could optimize my routines? :D
Todo:
- Compress the bullshit
- Spread the game
Preview:
Erstellt von Camtasia Studio 8 (http://cpc-live.com/barb128)
(Heavily cheated, just to demonstrate it)
Added the missing princess to scene 3:
(http://cpc-live.com/barbback3.png)
Quote from: Devilmarkus on 12:31, 28 October 13
- The routine is a bit slow, so the music stucks a little. Perhaps someone could optimize my routines? :D
If you post it here we can take a look at it ;)
As you wish:
Code infront the gamecode:
setbackground:
di ;; disable interrupts and store registers
push bc
push de
push hl
ex af,af'
detectopponent: ;; let's see in hidden screenram, which opponent is it
ld a,(&c7ed)
cp 2
jr c,bank1
cp 4
jr c,bank2
cp 6
jr c,bank3
bank4:
ld a,&c7
jp setbank
bank3:
ld a,&c6
jp setbank
bank2:
ld a,&c5
jp setbank
bank1:
ld a,&c4
setbank:
LD B,&7F
OUT (C),a
call color ;; let's patch the palette
copyscores: ;; copies the scores displayed into buffered image
LD DE,&49a8
LD HL,&c9a8
loopx:
push DE
push HL
LD BC,&20
ldir
pop HL
pop DE
ld A,&08
add D
ld D,A
ld A,&08
add H
ld H,A
cp &01
jr nz,loopx
copymode: ;; copies the lower info (MODE 1, MODE 2, DEMO) from screen to buffered image
LD DE,&47a2
LD HL,&c7a2
loopz:
push DE
push HL
LD BC,12
ldir
pop HL
pop DE
ld A,&08
add D
ld D,A
ld A,&08
add H
ld H,A
cp &07
jr nz,loopz
copyvariables: ;; copy the variables from hidden screen ram to buffered image
LD DE,&47d0
LD HL,&c7d0
LD BC,&47
ldir
LD DE,&4fd0
LD HL,&cfd0
LD BC,&47
ldir
copytofront: ;; copy buffered image to screen
LD DE,&c000
LD HL,&4000
LD BC,&4000
LDIR
LD Bc,&7Fc0
OUT (C),c
copytodoublebuffer: ;; copy screen area to doublebuffer
call &7ddd
restoreregisters: ;; restore the registers and re-enable the interrupts
ex af,af'
pop hl
pop de
pop bc
ei
originalcall: ;; do the original CALL, the game wanted to do
CALL &7D0E
RET
Code after gamecode:
color:
ld bc,&7f00+&4
out (c),c
ld a,(&c7ed)
cp 2
jr c,color1
color0:
ld c,&58
jp setcol
color1:
ld c,&57
setcol:
out (c),c
;; copy the red power dots to buffered image
LD DE,&4000
LD HL,&c000
loopy:
push DE
push HL
LD BC,&50
ldir
pop HL
pop DE
ld A,&08
add D
ld D,A
ld A,&08
add H
ld H,A
cp &0
jr nz,loopy
LD DE,&4050
LD HL,&c050
loopt:
push DE
push HL
LD BC,&50
ldir
pop HL
pop DE
ld A,&08
add D
ld D,A
ld A,&08
add H
ld H,A
cp &0
jr nz,loopt
ret
Important:
Optimized code may have max. the length of the original code I posted here.
Bigger code makes the game crash!
Edit: fixed a bug in upper code
This is ... remarkable! Believe it or not, I actually had a brief look into doing this not two weeks ago, as this was my favourite 1-on-1 fighter on the CPC. Though I was thinking to do it as a ROM version that would still be compatible with 64K, but it became apparent it was going to take more time than I had to spare on it, let alone more ROMs for the time being. Having to map in the ROM with the backgrounds on top of the screen where it needed to go looked like making things complicated with how much memory it uses. And now you've done this! :)
One thing:
Quote from: Devilmarkus on 13:12, 28 October 13
Added the missing princess to scene 3:
It looks like the princess is floating halfway above a step there, maybe move here down 4 pixels?
Really impressive job already done :o , hope you will find some help here.....
Quote from: Axelay on 14:03, 28 October 13
One thing:
It looks like the princess is floating halfway above a step there, maybe move here down 4 pixels?
I tried to, but then it looks more worse, believe me :)
Playable work in progress:
RUN"BARBAR"
Edit: Updated DSK
Will test it this evening on real machine ;)
Fixed the princess's position:
I updated the DSK here (http://www.cpcwiki.eu/forum/games/barbarian-128k/msg70144/#msg70144)!!!
I dont think there's any getting around the delay on the music if you disable interrupts the whole time you copy the screen. Do the interrupts really need to be disabled for the whole screen copy process? Or was there something in particular that causes the problem you can just di/ei either side of?
For memory being a problem, could you, instead of copying the red dots from the top of the visible screen to the new background and copying the whole thing back, copy everything but the top two lines from the new background to the visible screen so the dots remain untouched, and if memory is a problem, you could use those top two lines of the background screens in the extended RAM for code, with each of the backgrounds in extended RAM having the same code in the same place?
EDIT: Just remembered the interrupt routine itself sits inside the &4000-&7fff bank. Well there goes that idea. :-\
The dots are just 16 screenlines...
This won't cause any noticable speedup... (sadly)
As long the ram bank is swapped, I need to disable the interrupts, yes...
Well I guess further to that suggestion I made to cut down on the top two lines of copying, you could then use those two lines to copy with an unrolled string of ldi instructions rather than the single ldir, but that'll only be about 1/6 faster still.
LDI also needs more space I think...
First, I like that you have all the backgrounds stored in this 128k version.
But I have a question:
In the game, the background is stored in ram like a sprite (I think).
So in the 128k version, you can just replace this sprite and then all works ok?
No need to save the health, scores etc?
or am I wrong?
I too was thinking of doing the same idea (all backgrounds in ram/rom).
But also I was going to change it so that it shows a menu instead of changing with "mode 1" and "mode 2", because I wanted to support other joysticks and make it easy to control on gx4000/6128plus with joystick only.
Any plans to have the high-score table or other things like this?
Nice, is there any way of giving the other sprites more colours? They always looked a little flat compared to the Goblin IMO.
exactly what I was thinking. are the sprites colour limited? and can the backgrounds be replaced?
Quote from: arnoldemu on 16:52, 28 October 13
First, I like that you have all the backgrounds stored in this 128k version.
But I have a question:
In the game, the background is stored in ram like a sprite (I think).
So in the 128k version, you can just replace this sprite and then all works ok?
No need to save the health, scores etc?
or am I wrong?
I too was thinking of doing the same idea (all backgrounds in ram/rom).
But also I was going to change it so that it shows a menu instead of changing with "mode 1" and "mode 2", because I wanted to support other joysticks and make it easy to control on gx4000/6128plus with joystick only.
Any plans to have the high-score table or other things like this?
All 4 backgrounds are stored as 16k binaries.
I do like this:
- Copy GUI (scores, MODE display etc...) to buffered background @ given rambank (c4,c5,c6,c7)
- Copy some variables from unseen screenram (C7D0, E7D0) to buffered background
- Copy 16k screen (bufferedbackground) to front
- The game itself has a CALL &7DDD -> this copies the needed area (playfield) into the game's double buffer. This I also call here now, to copy from screen to game doublebuffer.
You can see that in my source code here:
Barbarian 128k (http://www.cpcwiki.eu/forum/games/barbarian-128k/msg70140/#msg70140)
It makes no sense to have smaller screens, as the snakes also appear different in each scene. (Sure, to spare some ram, this could be a solution, but then every scene would have the same snakes @ border)
I don't plan anything else, the sprites are very cut into small snippets, so it makes no fun to edit them.
The game itself is only patched by replacing a CALL &7D0E (somewhere in gamecode) against a CALL setbackground.
...in-game music? :D
Quote from: Gryzor on 18:40, 28 October 13
...in-game music? :D
Barbarian already has in-game music. Just press F2 during playing...
*facepalm*
I had totally forgotten about that, but I mean with the sfx...
Quote from: Gryzor on 19:05, 28 October 13
I mean with the sfx...
3 channels music + 3 channels sfx?
Ask TotO ;)
Is the sfx really 3 channels? Wow, can't hear it.
At least 2 channels. Sometimes you can hear 2 "samples" @ the same time...
Well ok, these two channels could take precedence over the tune... Really not sure how possible it is...
Funny,
I was just having a Barbarian session, and i was wondering if it was possible to do exactly what you did.
Congrats!
Herr... "Pokes : No" gives infinite live and one shot victory? :o
what about 4bpp coded sprites instead ?
I found out the sprites (warrior's) are in 2bpp (mode1) as can be seen by the find fraphics function on winape.
it is converted, recoloured, and masked, hence the mode1 limitation despite being in mode0 at the display.
it take perhaps some CPU, but it saves a lot lot lot of RAM indeed...
Just imagine sprites in 4bpp, with both flips (left or right direction) and different spriteset for both opponents in order to have "colour swap"...yeah that's right.
May weight like 8 time the Datas.
instead it converts 2bpp into Mode0, choose the colours as well, may even flip left-right.
thx code (pun!) there are only 2 warriors on screen... but lots of different movements, so quite a lot of tiles for sprites.
Not sure that to manage 8x time the datas would be even more CPU efficient (=faster), would it ?
Many 1vs1 fighting games are quite slow on CPC actually... ut I think it is unfair... even without Hardsprites, the CPC could certainly handle on 2 well animated sprite betterly, provided those games rarely have scrolling...
But to mask something can be quite heavy indeed, need to get a patch of background to erase previous srpites (the ones from the last frame) then put new ones (masked and calculated) on those...
Controls and A.I (CPU opponent needs to be somewhat challenging)... colision detection... surely the CPU has some heavy job here and then anyway...
Is this even double buffered ?
So yeah, to patch to get a true history mode and single loading is great... but a 128K version could do even more actually... and multiload is great with Disks.
Quote from: Devilmarkus on 14:52, 28 October 13
As long the ram bank is swapped, I need to disable the interrupts, yes...
Could that final CALL &7ddd be made after the EI?
Quote from: remax on 01:15, 29 October 13
Herr... "Pokes : No" gives infinite live and one shot victory? :o
Sorry about that.
I forgot to remove the pokes after loading...
So, edit line 20 in BARBAR.BAS and remove the 2 POKEs here...
(Or download this DSK here)
[attachurl=2]
Calling &7DDD after EI causes a bad palette... :D
Quote from: Devilmarkus on 11:42, 29 October 13
Sorry about that.
I forgot to remove the pokes after loading...
So, edit line 20 in BARBAR.BAS and remove the 2 POKEs here...
(Or download this DSK here)
[attachurl=2]
Calling &7DDD after EI causes a bad palette... :D
Thanks ::)
Hi there !
Let me correct on this : the sprites here are not 2bpp like "mode 1", but 2bpp like "multi-color mode" on the Commodore 64 ! .... yes, remember all of this was drawn on the C64, definitively a lesser (but faster) machine ! ;D 1 mhz CPU and color-clash ... and they did it : Barbarian, the Ultimate Warrior... :P
Quote from: MacDeath on 03:18, 29 October 13
what about 4bpp coded sprites instead ?
I found out the sprites (warrior's) are in 2bpp (mode1) as can be seen by the find fraphics function on winape.
it is converted, recoloured, and masked, hence the mode1 limitation despite being in mode0 at the display.
it take perhaps some CPU, but it saves a lot lot lot of RAM indeed...
Just imagine sprites in 4bpp, with both flips (left or right direction) and different spriteset for both opponents in order to have "colour swap"...yeah that's right.
May weight like 8 time the Datas.
instead it converts 2bpp into Mode0, choose the colours as well, may even flip left-right.
thx code (pun!) there are only 2 warriors on screen... but lots of different movements, so quite a lot of til
[...]
The C64 was doing that too with 64k only ;D ok the video RAM space needed is halved.
I applaude to this great initiative that eradicate the limitation that was obscuring the fact that the CPC version is definitively better because prettier.
Quote from: Devilmarkus on 12:31, 28 October 13
For me, the most annoying limiatation was, that you have to select a scene on startup.
QuoteLet me correct on this : the sprites here are not 2bpp like "mode 1", but 2bpp like "multi-color mode" on the Commodore 64 ! .... yes, remember all of this was drawn on the C64, definitively a lesser (but faster) machine ! 1 mhz CPU and color-clash ... and they did it : Barbarian, the Ultimate Warrior...
true too. the method had many advantages...No need to redo graphics AND would save some precious RAM for those CPC64K...
QuoteThe C64 was doing that too with 64k only ;D ok the video RAM space needed is halved.
True too.
2bpp graphics in wide pixels... 4 colours per attributes.
the attribute table having some weight but still far lighter than 4bpp for a whole screen.
CPC in 64K :
native graphics are almost twice heavier...
"VRAM" uses more on the RAM (a whole 16K for the 160x200)
More code because no hardwired sprites... need to perform soft conversion from 2bpp to 4bpp, need to mask so a buffer for the background may be needed, parts of it must be kept in the RAM to refresh, while hardsprite based can just leave the background as it is. On CPC there are some ways to do it : all parts of the screen that may get animation (sprites) over it are to be stored so you can always get again the fresh background...or else you keep a smaller buffer for the parts/characters that are covered by the sprites, but this would be actually heavier on CPU I guess... and you may risk loosing bits if bugs or faulty thing... (or not ?).
sad part is that a CPC could really compete actually quite well with C64 for most games without scrolling provided it was 128K only.
Hell even having a CPC480 or CPC496 could be enough to save many speccy48 ports from those RAM saving technics.
64K CPCs are so underRAMed.Fano learnt and proved so much when dealing with Rick Dangerous and R-Type...
To me that is even a miracle some actually managed to produce good games with CPC464.
Fun to see the PC CGA version also share the same 8bit sprites as CPC and C64... "wide pixels" lol...
When talking of C64 version the 64k limit was certainly reached as it doesn't have all the backgrounds simultaneously in memory either: Game is split into 2 parts, "combat practise" (endless) and "fight to the death" (completable) with 2 different backgrounds each, which need to be loaded separately.
wops... sorry for the confusion... so it was 2x2 and not 4x1 ... thank you for the correction !
Well... thanks to Devilmarkus, the CPC version is not only the prettiest 8bit version, it is now the richest version too ! 8)
Quote from: romppainen on 02:45, 30 October 13
When talking of C64 version the 64k limit was certainly reached as it doesn't have all the backgrounds simultaneously in memory either: Game is split into 2 parts, "combat practise" (endless) and "fight to the death" (completable) with 2 different backgrounds each, which need to be loaded separately.
The CPC version is actually even somewhat pretier than 16bit versions IMO...
Backgrounds are really well lavished on CPC.
Fiddling on the game's palette and pixels...
Also changed the name to "Death Sword" as it's the American name of this game...
The scenes so far:
(http://cpc-live.com/scene1.png) (http://cpc-live.com/scene1.png)
(http://cpc-live.com/scene2.png) (http://cpc-live.com/scene2.png)
(http://cpc-live.com/scene3.png) (http://cpc-live.com/scene3.png)
(http://cpc-live.com/scene4.png) (http://cpc-live.com/scene4.png)
Will not show more details yet, but I have help from MacDeath and TotO ;)
And I'm sure, SyX is getting mad with my questions :P
Quote from: Devilmarkus on 07:13, 02 November 13And I'm sure, SyX is getting mad with my questions :P
No, specially... but you have an special skill for getting me in my most busy moments of the day :P
Quote from: SyX on 15:07, 02 November 13
No, specially... but you have an special skill for getting me in my most busy moments of the day :P
Same here. :P :)
Progress: ~98% ;)
New video:
Erstellt von Camtasia Studio 8 (http://cpc-live.com/barb128)
Looking for some people who can test it on the real machine:
- CPC 6128
- CPC 664 and 464 (expanded to 128k at least)
- CPC's with extra ROMs, Expansions etc...
The game does not work on CPC+!
Why not on cpc+ ?
If it's the keyboard test you can correct it ;)
We tested it on a 6128+ and the GFX gone mad...
(Perhaps a bad transfer, who knows?)
But I'm still looking for people, who can check it on a real CPC... !??!
How to patch it for CPC+? (Keyboard)
The DSK available on cpc-power.com is good for emulators, but doesnt work on a real CPC+
Here's the keyboard scan for Barbarian: (+ more code? This is a codepart which is called from somewhere)
LD B,&F7 ;;820C: .. 06 F7
LD C,&82 ;;820E: .. 0E 82
OUT (C),C ;;8210: .I ED 49
LD HL,&835E ;;8212: !^. 21 5E 83
XOR A ;;8215: . AF
LD D,&0B ;;8216: .. 16 0B
PUSH AF ;;8218: . F5
LD C,(HL) ;;8219: N 4E
LD B,&F4 ;;821A: .. 06 F4
OUT (C),A ;;821C: .y ED 79
LD B,&F6 ;;821E: .. 06 F6
IN A,(C) ;;8220: .x ED 78
OR &C0 ;;8222: .. F6 C0
OUT (C),A ;;8224: .y ED 79
AND &3F ;;8226: .? E6 3F
OUT (C),A ;;8228: .y ED 79
LD B,&F4 ;;822A: .. 06 F4
OUT (C),C ;;822C: .I ED 49
LD B,&F6 ;;822E: .. 06 F6
LD C,A ;;8230: O 4F
OR &80 ;;8231: .. F6 80
OUT (C),A ;;8233: .y ED 79
OUT (C),C ;;8235: .I ED 49
POP AF ;;8237: . F1
INC A ;;8238: < 3C
INC HL ;;8239: # 23
DEC D ;;823A: . 15
JR NZ,&8218 ;;823B: . 20 DB
LD D,&0A ;;823D: .. 16 0A
LD E,&00 ;;823F: .. 1E 00
LD HL,&8352 ;;8241: !R. 21 52 83
LD B,&F7 ;;8244: .. 06 F7
LD C,&82 ;;8246: .. 0E 82
OUT (C),C ;;8248: .I ED 49
LD B,&F4 ;;824A: .. 06 F4
LD A,&0E ;;824C: >. 3E 0E
OUT (C),A ;;824E: .y ED 79
LD B,&F6 ;;8250: .. 06 F6
IN A,(C) ;;8252: .x ED 78
OR &C0 ;;8254: .. F6 C0
OR E ;;8256: . B3
LD C,A ;;8257: O 4F
AND &3F ;;8258: .? E6 3F
OUT (C),C ;;825A: .I ED 49
OUT (C),A ;;825C: .y ED 79
INC B ;;825E: . 04
LD C,&92 ;;825F: .. 0E 92
OUT (C),C ;;8261: .I ED 49
DEC B ;;8263: . 05
OR &40 ;;8264: .@ F6 40
OUT (C),A ;;8266: .y ED 79
LD B,&F4 ;;8268: .. 06 F4
IN A,(C) ;;826A: .x ED 78
CPL ;;826C: / 2F
LD (HL),A ;;826D: w 77
INC HL ;;826E: # 23
INC E ;;826F: . 1C
DEC D ;;8270: . 15
JP NZ,&8244 ;;8271: .D. C2 44 82
RET ;;8274: . C9
So, who can patch it? The method from T&J doesnt work here.
QuoteLooking for some people who can test it on the real machine:
- CPC 6128
I can test the game in my cost down 6128 if you want.
Would be cool!
I sent you a PM with the informations.
BTW.: Thanks to César (CNGSoft) I patched the keyboard routine for CPC+ (He rewrote the complete PSG- and Keyboard code!)
Quote from: Devilmarkus on 18:21, 04 November 13
So, who can patch it? The method from T&J doesnt work here.
I have the original version of Barbarian (Dump No.4 on CPC Power (http://cpc-power.com/index.php?page=detail&onglet=dumps&num=40)) and I've managed to patch it to work on the Plus as well:
org &81ab
ld hl,&82bc
ld bc,&f40e
out (c),c
ld b,&f6
in a,(c)
and &30
ld c,a
or &c0
out (c),a
out (c),c
inc b
ld a,&92
out (c),a
set 6,c
scankey:
ld b,&f6
out (c),c
ld b,&f4
in a,(c)
cpl
ld (hl),a
inc hl
inc c
ld a,c
and &0f
cp &0a
jr nz,scankey
ret
Have tested it in WinApe and it works, but not had a chance on a real Plus yet.
We did this:
(complete replacement for PSG and Keyboard scanning)
ld bc,$F782
out (c),c
ld hl,$835E
ld e,0
barb128k_psg:
ld b,$F4
out (c),e
ld bc,$F6C0
out (c),c
out (c),0
ld b,$F4
ld a,(hl)
out (c),a
ld bc,$F680
out (c),c
out (c),0
inc hl
inc e
ld a,e
cp $0B
jr c,barb128k_psg
ld hl,$8352
ld e,$40
barb128k_kbd:
ld bc,$F782
out (c),c
ld bc,$F40E
out (c),c
ld bc,$F6C0
out (c),c
out (c),0
ld bc,$F792
out (c),c
dec b
out (c),e
ld b,$F4
in a,(c)
cpl
ld (hl),a
inc hl
inc e
ld a,e
cp $4A
jr c,barb128k_kbd
ret
defs &15
Last DEFS &15 is because the new code is &15 bytes shorter than the original code.
It's perhaps located @ different area in ram, because my game is based on BARB2A.
(BARB1A,1B don't have Draxx, and BARB2B was way too large to patch around... BARB2A did not remove Draxx and Princess from scene, but thanks to Fano, I also managed this....)
First test:
CPC 6128:
This afternoon.
I can do some testing with real 6128 during next weekend if still needed.
We already tested it on a CPC 6128 today, and also dragon will do a test I think.
But thanks for the offer.
Who could test it on an expanded 464/664 with 128k ram at least?
And also on a CPC 6128 plus...?!?
Quote from: Devilmarkus on 15:36, 05 November 13
We already tested it on a CPC 6128 today, and also dragon will do a test I think.
But thanks for the offer.
Who could test it on an expanded 464/664 with 128k ram at least?
And also on a CPC 6128 plus...?!?
I can test it on 6128 plus, and 464 with 512k ram extension.
Quote from: gerald on 16:01, 05 November 13
I can test it on 6128 plus, and 464 with 512k ram extension.
PM sent ;)
mr_lou I think, also tests it on his homebrew CPC plus, but its good to have 2 plusses in the test.
Info:
The code is final now. Just a few pixel changes are planned here and there.
Few impressions: (Got much help from TotO and MacDeath!)
(http://cpc-live.com/back1.png)
(http://cpc-live.com/back2.png)
(http://cpc-live.com/back3.png)
(http://cpc-live.com/back4.png)
These screens maybe are not the final results yet!
Those screens are far superior, far better palettes than the original. Good work! Better trees, better ground, better castle, better fighting pit.
Good news: The game also works on CPC+
I also patched the loader to run on a CPC 464 (Was a BASIC issue that it didn't start on Gerald's CPC)
Sadly his ram expansion is on an emancipation trip and denied to work...
Good luck, Gerald, fixing your ram expansion! :)
And thanks for testing...
I hope you can also share some photos here? :)
Btw.: This is, what happens, when the user has a bug: (Joke! Don't take this serious, but also such things happen when testing things)
Markus Hohmann's Barbarian hack prototype - test 1 (http://www.youtube.com/watch?v=t2Fz9k_MWfU#)
(no worries, freemac, you just ran the bad file from disk) :laugh:
freemac's test #2:
Markus Hohmann's Barbarian hack prototype - test 2 (http://www.youtube.com/watch?v=J4e_ZYAVypM#)
Quote from: Devilmarkus on 21:12, 05 November 13
Sadly his ram expansion is on an emancipation trip and denied to work...
Good luck, Gerald, fixing your ram expansion! :)
Well, I think luck will not be enough :(
I've re-tested on 6128 with the prototype, and all is OK. With the final PCB, I get crash. My memory test pass on both version. So it looks like a timing issue >:( .
However, none of them (proto and final) works as expected on 464 (ie base RAM is overwritten). I will have to check the PLD code for 464 support .
Quote from: Devilmarkus on 21:12, 05 November 13
I hope you can also share some photos here? :)
When 464 works !!!!
Do you perhaps have too many extra ROMs installed?
Death Sword 128k consumes RAM up into ROM regions....
Quote from: Devilmarkus on 22:06, 05 November 13
Do you perhaps have too many extra ROMs installed?
Death Sword 128k consumes RAM up into ROM regions....
:o good hit, at least for the crash on 6128.
No more crash with the final version when using a blank flash. The proto did not have any.
However, I only had FutureOs ROMs installed.
Quote from: Devilmarkus on 21:15, 05 November 13
Btw.: This is, what happens, when the user has a bug: (Joke! Don't take this serious, but also such things happen when testing things)
Markus Hohmann's Barbarian hack prototype - test 1 (http://www.youtube.com/watch?v=t2Fz9k_MWfU#)
(no worries, freemac, you just ran the bad file from disk) :laugh:
And I thought it was the floppy .... :)
Proved: Death Sword does not work together with FutureOS...
Just tested it.
It also don't work with SymbOS... Just to make it clear ;)
Really: The game has (without any extra roms) perhaps a few 3-6 bytes ram free...
Quote from: Devilmarkus on 22:55, 05 November 13Really: The game has (without any extra roms) perhaps a few 3-6 bytes ram free...
Could a binary loader do the trick ?
When the game is finished, I want to compact it.
I hope that helps then...
Here you can see the reason:
[attachimg=1]
As you can see, it already assembles > regular HIMEM (But not too much so that AMSDOS isn't destroyed yet)
Managed to get it working with FutureOS ROMs:
I reduced a random routine.
I first used this method I found here in our forum:
random: ;; Let's choose a random level for DEMO mode
ld a,(seed)
ld b,a
add a,a
add a,a
add a,b
inc a
ld (seed),a
ld a,20 ;; Divide Begins here
ld c,a
ld a,0
ld hl,(seed)
ld b,16
divide:
add hl,hl
rla
cp c
jr c,end_divide
sub c
inc l
end_divide:
djnz divide
and 7
call &6F8F ;; Do the original CALL the game wanted
ret
seed:
defb 0
defb 0
Result:
Assembled in 8.205s from &1744 to &A6D4 length is &8F91
I reduced it to a minimum and also optimized some other codes (by moving them into spare places of the main binary):
random: ;; Let's choose a random level for DEMO mode
ld a, (seed)
ld b, a
rrca ;; multiply by 32
rrca
rrca
xor &1f
add a, b
sbc a, 255 ;; carry
ld (seed), a
and &07 ;; we only have 8 opponents in Death Sword
call &6F8F ;; Do the original CALL the game wanted
ret
Result:
Assembled in 8.324s from &1744 to &A6AF length is &8F6C
Quote from: Devilmarkus on 22:06, 05 November 13
Do you perhaps have too many extra ROMs installed?
Death Sword 128k consumes RAM up into ROM regions....
Define "too many extra ROMs".
Maybe that's why it doesn't work on my CPC+ then.
Bryce says he tested all RAM.
Of course, it's always possible that they broke afterwards, or that they need to be re-seated in the sockets or something.
Other 128k games I've tried works fine.
Too many:
2 extra ROMs already made the game crashing...
I think two joystick for play will be good also ;)
And why don't adapt palette to CPC+ ?
1 Joystick is enough, as the game doesnt provide a 2 player game.
No way to change the palette for CPC+ because there really is not enough ram free to do that.
Added anti-poke protection.
The classic POKEs for unlimited lifes or "1 hit only" will not work anymore...
Tested the game:
CPC with 11 extra roms: The game starts well.
CPC with 12 extra roms or more: Impossible to play it.
Quote from: Devilmarkus on 14:47, 06 November 13
1 Joystick is enough, as the game doesnt provide a 2 player game.
Yes it does.
That is "mode 2" I believe.
I am sure there is a mode with 2 player on barbarian.
Quote from: Devilmarkus on 16:39, 06 November 13
Tested the game:
CPC with 11 extra roms: The game starts well.
CPC with 12 extra roms or more: Impossible to play it.
11.5 roms?? :laugh: it sometimes works and sometimes not?
MODE 1 = 1 player, joystick
MODE 2 = 1 player, keyboard
MODE 3 (not available in BARB2A,BARB2B): maybe is 2 player mode...
As the game is based on the BARB2A binaries, MODE 3 isn't available... sorry
Sure, it's MODE 3 ... Look to be removed here.
EDIT: Late... ;D
Quote from: Devilmarkus on 18:40, 06 November 13MODE 1 = 1 player, joystick
MODE 2 = 1 player, keyboard
MODE 3 (not available in BARB2A,BARB2B): maybe is 2 player mode...
As the game is based on the BARB2A binaries, MODE 3 isn't available... sorry
Reason is rather obvious, game works exactly like intended due to main engine being splitted in two:
Quote from: romppainen on 02:45, 30 October 13Game is split into 2 parts, "combat practise" (endless) and "fight to the death" (completable) with 2 different backgrounds each, which need to be loaded separately.
The "combat practise" part, which have option for 2 player game, contain forest and valley levels while both indoor levels belong to "fight to the death part" which is single player only.