Crap 0.1 first assembly project

Show us what you're working on, (preferably with screenshots).
Post Reply
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Crap 0.1 first assembly project

Post by Nomad »

Well further my resolution for 2018 to spawn my very own crap assembly game I will put my laughable progress here for all to have a chuckle at and hopefully give me a few pointers/obiwan like advice along the way to bring this baby home!

So at the moment I have this...

Image

Mmmm just soak it in... Yes friends, its a chess board. However it needs the chessmen and the pawns. That is the next step, that and fixing the board colour - (needs to be green and white really..) still that is pretty smooth sailing.

In the spirit of crap games, you will need two players, who enter there moves via the keyboard (none of that cursor stuff... well not at the moment anyway..). Because there is no chess computer - no complicated AI, and all that other headache causing stuff. All the 'game' will do is accept user input from the two players, and move the chessmen/pawns about the board, removing the pieces when needed.

That will just require a non-vacant square check, if non-vacant remove the piece from the board and replace with the new piece. pretty simple.

But like a fool I decided to tackle the background first. (well it pretty...)

The assembly code was based of a checker pattern program I found on you tube and abused...

Next task is to create the sprites, then the input, then think about the animation, then the 'rules'. mmmmm will add some more cosmetic fluff like a title bar, infobar at the bottom, to make it less of a cheat i will set the border, paper, in the assembly portion and not the basic boot loader next time also.

This is the listing for my 'project'.. lol this was my first crack at it...

Code: Select all


org 50000
	ld hl, 22528	;start of screen page
	ld a, 4		;set a to 8 (height)
loop:	ld b, 4		;set b to 8 (width)
row1a:  ld (hl), 0	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 0      ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 0	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 0      ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row1a      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row1b:  ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row1b      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row2a:  ld (hl), 127	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127    ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127    ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row2a      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row2b:  ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row2b      ;jump row1 if non-zero (b)
        dec a           ;decrement a
        jr nz, loop     ;jump loop if non-zero (a)
        ret
end 50000
That is ugly and I was ashamed at my lack of a third loop to reduce all those filthy repeated blocks... I had to do something...

Code: Select all

org 50000
	ld hl, 22528	;start of screen page
	ld a, 4		;set a to 8 (height)
loop:	ld b, 4		;set b to 8 (width)
        
row1a:  ld c, 4         ;set c to 4 (square)     
row1aa:  ld (hl), 0	;colour is black block
	inc hl          ;increment hl (screenpos)
        dec c
	djnz row1aa
        ld c, 4
row1ab:	ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        dec c
        djnz row1ab
        djnz row1a      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row1b:  ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row1b      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row2a:  ld (hl), 127	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127    ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127	;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 127    ;colour is black block
	inc hl          ;increment hl (screenpos)
	ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row2a      ;jump row1 if non-zero (b)
        ld b, 4         ;reset b to 16
row2b:  ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 127    ;colour is black block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        ld (hl), 0      ;colour is white block
        inc hl          ;increment hl (screenpos)
        djnz row2b      ;jump row1 if non-zero (b)
        dec a           ;decrement a
        jr nz, loop     ;jump loop if non-zero (a)
        ret
end 50000
but what happened was this...

Image

Who would have thought that a 3 deep nestled loop would go wrong? :) well I need to look at the code again and try and figure out how i screwed it up..
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Crap 0.1 first assembly project

Post by R-Tape »

Why not go for a square grid? Most Speccy chess games use tiles (16 x 16 pixels), or even UDGs? (8x8) that'd be easier to use with your chess pieces too. Also remember that attribute 0 means you won't see your sprites! (black PAPER and INK).

Interested to see how this progresses.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

R-Tape wrote: Sat Dec 30, 2017 3:26 pm Why not go for a square grid? Most Speccy chess games use tiles (16 x 16 pixels), or even UDGs? (8x8) that'd be easier to use with your chess pieces too. Also remember that attribute 0 means you won't see your sprites! (black PAPER and INK).

Interested to see how this progresses.
I was hoping to use larger sprites but that might be a big headache, like you say. I tried the 8x8 but that seems a bit on the small side. The 16x16 would be ok and would have enough room on the side for the moves.

You are right about the colour - I realised after I had loaded the paper/border that I should have gone for a green and white board instead. That is what I am doing now is switching the black to green as we speak :)

and done..

Image

Next issue is that weird message printing across the board.. hmmm.

:) after having a look at the rest of the archive it seems it would be a little bit to 'radical' to have a non-square chess board. 16x16 it is . Will fix it tomorrow. Then the fun of creating the sprites for the pieces.
Thanks for the tips.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: Crap 0.1 first assembly project

Post by PROSM »

Nomad wrote: Sat Dec 30, 2017 3:35 pm Image

Next issue is that weird message printing across the board.. hmmm.
That weird message is from when the program was loaded into memory. It's simply remnants of the screen left from BASIC. To get rid of it, you need to clear the bitmap area of the screen before you draw your board, like this:

Code: Select all

	ld hl,16384
	ld de,16385
	ld bc,6143			; Length of the screen minus one
	ld (hl),0
	ldir				; Clear the screen
The above fills the bitmap area with all zeroes, thus getting rid of the message.

I hope this helps you with the message problem.
All software to-date
Working on something, as always.
User avatar
Morkin
Bugaboo
Posts: 3250
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: Crap 0.1 first assembly project

Post by Morkin »

Nice one - you gotta start somewhere and I remember how happy I was just to get something printed on the screen.

Also part of the fun is improving and debugging your own code, and working out different ways of doing something.
My Speccy site: thirdharmoniser.com
User avatar
MatGubbins
Dynamite Dan
Posts: 1237
Joined: Mon Nov 13, 2017 11:45 am
Location: Kent, UK

Re: Crap 0.1 first assembly project

Post by MatGubbins »

Well done and congratulations for getting this far with machine code. World domination will be soon on the list!
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

PROSM wrote: Sat Dec 30, 2017 4:15 pm
That weird message is from when the program was loaded into memory. It's simply remnants of the screen left from BASIC. To get rid of it, you need to clear the bitmap area of the screen before you draw your board, like this:

Code: Select all

	ld hl,16384
	ld de,16385
	ld bc,6143			; Length of the screen minus one
	ld (hl),0
	ldir				; Clear the screen
The above fills the bitmap area with all zeroes, thus getting rid of the message.

I hope this helps you with the message problem.
Thank you fella, that solved the problem.

Got the first screen done also...

Image

Image

I love it when a crap game comes together...
Last edited by Nomad on Sun Dec 31, 2017 6:28 am, edited 1 time in total.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Morkin wrote: Sat Dec 30, 2017 5:00 pm Nice one - you gotta start somewhere and I remember how happy I was just to get something printed on the screen.

Also part of the fun is improving and debugging your own code, and working out different ways of doing something.
In fairness I had a lot of help from blogs, and posts from the forums (WOS and here). Especially the series about the connect four game on youtube. Darryl Sloan https://www.youtube.com/watch?v=1gHlMpO8gqw

I had tried to give z80 a go a few times before and never really got beyond the add, sub, repeat addition stage. It is really surprising how many great sources of information about assembly on the z80 came out and started sharing info in the last 10 years or so.

When I saw what had been done with the graphics engines was another kick in the pants to do something - it was now possible to create games that had the potential to look better than anything that was achievable back in the day. Fair enough it will take time to get to that level but its a good long term goal.

But yea I can't deny when I saw the 'otherwise square shaped' chess board on the screen I was sat with a big grin on my face.
MatGubbins wrote: Sat Dec 30, 2017 5:07 pm Well done and congratulations for getting this far with machine code. World domination will be soon on the list!
Can only hope, the plan is once I have the first crap game in the bag, I can use that as the template to create other variants. That is partly why i started with board game - I can use the skeleton for something else easy after and focus on adding on more features. That seems a better approach than going for the equivalent of gift from the gods on a first project haha. More a slow climb of many many crap games getting a little bit better each time. I figure that is more realistic also. I might never have the 'skilz' to make a complicated game but I know I can make a crap game :D and being real - I am never going to get to a place to create a complex game without putting in the work with the crap first :D
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

'Music' for the title screen is done. Thank you Beepola that is a cracking little app and it runs just fine on linux with Wine.

Now just need to research how to cobble all these bits together, knock up a loading screen and that is another hurdle crossed. 8-)

I was going to crack on with the graphics but I figured get the tune done first and move on. It's one less thing to do. Plus I can see graphics/sprites being much harder 9 sprites need to be created (will just switch the colour for the different players.

Not sure If I can attach the tap file so you can listen to the little ditty. So I uploaded it to a third party.
https://nofile.io/f/ZnEd5pR56Rg/crapin.tap
AndyC
Dynamite Dan
Posts: 1386
Joined: Mon Nov 13, 2017 5:12 am

Re: Crap 0.1 first assembly project

Post by AndyC »

Nomad wrote: Sun Dec 31, 2017 6:04 am Can only hope, the plan is once I have the first crap game in the bag, I can use that as the template to create other variants. That is partly why i started with board game - I can use the skeleton for something else easy after and focus on adding on more features. That seems a better approach than going for the equivalent of gift from the gods on a first project haha. More a slow climb of many many crap games getting a little bit better each time. I figure that is more realistic also. I might never have the 'skilz' to make a complicated game but I know I can make a crap game :D and being real - I am never going to get to a place to create a complex game without putting in the work with the crap first :D
That's honestly the best approach. I've seen so many people who start off believing that a few weeks of assembly and their first attempt will be the equivalent of Rainbow Islands and then give up with frustration because they barely get to Pong. Start small and not overly ambitious, know that you will definitely do things which, as you improve, you will look back on as dumb ideas. Each step takes you further along until eventually you're producing things far more complicated than you ever imagined you would do.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

To be honest today was not so fast progress, but what progress there was was ok. Player input is now a thing, in a basic way. But at least the program now looks at 23560, compares it to a bunch of different keys and then does a bunch of stuff. ala the menu.

That said, what didn't go so well today was... tommygunn refused to work just kept throwing exceptions all over the shop when i ran it with wine, zxpaintbrush was also freaking out. So I think perhaps my install of wine is borked. (trump voice) Sad.

I am thinking of just getting some poverty desktop to put a copy of windows on just to run these dev apps as most of the spectrum development programs seem to be windows based...

So got some stuff on the screen, got my texts going where I want them, the graphics are a bit of an enigma but I finally figured out what I was doing wrong with the udgs (not treating them like a string/char). I need to spend more time with the sprite side of things and get a handle on that. Then everything will be more smooth.

Thing that went much easier than expected was the musical side of the project, lol that was done in under a min (and it shows - but then a crap game needs crap music :D)
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Its the 1st of January, So I have 364 days to complete this crap game. Things are looking good.
1. SevenUp works fine, so its now much less of a hassle doing specky graphics. That was the first good news of the day.
2. Audio is already ready to go into the game. Sound effects got done this morning. (farts and sweeps)
3. Player movement is done.
4. boundary checking is done.
5. Pointer is done.
6. plus other minor stuff.

So things left that need to be fixed - I thought just do a basic background this time, I will do a fully tiled master work some other game. But at the moment it would be nice to get this done and move on. With that in mind, the layout of the main game screen is pretty easy - just print the coordinates for the board along the grid, and have the player moves along the right hand side, a basic menu system and a help screen and besides the animation of pieces, and some kind of print routine for the game history its done.

My understanding is back in the day some commercial crap spectrum titles were written and sent out to customers in 28 days. Would be fun to see if I can complete this in 28 days. I used to think those kinds of turn around times were unbelievable but now I can see how it could be done - especially if a guy knew what he was doing and had a template already/old code from other projects he could re use. Doing something impressive though would have still taken time.

Happy new year party people!
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 2: (363 days left..)

Got the pawn sprite done. got a bunch of libraries for z80 assembly on the spectrum so while i feel its a little bit of a short cut, it greatly improves my noob chances of getting something finished that looks ok. I think even a crap game has some standards...

1. It should be better than a basic type-in from the magazines of the time. In other words for this challenge to be complete it should have stuff that my 6 year old self would have sat down and said "damn I can't do that in basic..." Something that could have realistically been sold for a few quid in the back of a magazine at the start of the spectrum era. The use case is - guy pays 5 pounds and is instantly disappointed but not enough to demand a refund.

2. No copy-pasta, I need to actually understand what the program is doing. This is a learning exercise first and foremost so I can't just use a game creator program. Not saying I have to write everything in a cave, but it should be understood first before being used. I agonised over using the libraries because of this but its not on the same level. I can always learn how to do the fancy sprite stuff next time.

With that in mind today was pretty productive, figuring out what can be done with the libraries, and then that will leave me tomorrow with a list of stuff I still have outstanding. Will get the library demos working tonight and go from there.

Going to finish the Jonathan Cauldwell guide, that was extremely useful. http://s3.spanglefish.com/s/22323/docum ... mes1.0.zip

Also well worth a look http://sgate.emt.bme.hu/patai/publicati ... index.html for general Z80 assembly.

The main library I have been looking at was by Sebastian Mihai. libzx. http://sebastianmihai.com/main.php?t=13 ... y-language
dfzx
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: Crap 0.1 first assembly project

Post by dfzx »

Nomad wrote: Tue Jan 02, 2018 9:04 am The use case is - guy pays 5 pounds and is instantly disappointed but not enough to demand a refund.
:lol: :lol: :lol: ROFLMAO! :lol: :lol: :lol:

Keep going, and keep commentating. I love threads like this.
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
Wall_Axe
Manic Miner
Posts: 491
Joined: Mon Nov 13, 2017 11:13 pm

Re: Crap 0.1 first assembly project

Post by Wall_Axe »

if yer usin linux you can use pasmo i think, or some other assembler
make files are useful
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Wall_Axe wrote: Tue Jan 02, 2018 1:54 pm if yer usin linux you can use pasmo i think, or some other assembler
make files are useful
Pasmo is what I am using at the moment, I like how you can generate the tap files with it. :)
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 3: (362 days left)

Got all arty-farty with screen painter :lol: The idea was to have a main background that was:

1. Garish to the point of migraine inducing, colour theory should be actively avoided.
2. I was lazy and figured the board is not going to move so might as well plonk it on the background.

Image
Gents, I think everyone is in agreement :D

Now the only thing I have to do is put this bad boy into the crap program... At the moment I am looking at libzx and the way that the background is loaded there is pretty straight forward however the background is not in the same format as what you get from the tools when I save as bin or as a code.

Its expecting

Code: Select all

 db $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
but that's not what the screens save as :(

I frankly don't trust myself to not make a mistake manually editing the whole bin file. Will try and figure out a way to automate this. But if someone can point out where I am going wrong or how i can just load the bin of the background into the program that would be fabulous.

Faffing around with the background loader and screen paint was not the only thing project related that got done today. In the spirit of the challenge. I figured the type of deviant that would create such crap and actually try and sell it to the unsuspecting public would want to maximise the profit potential. Therefore a port to other platforms would be desirable. But to keep within the spirit of the challenge it should be a lazy port with no optimisations just the bare minimum to get it working on the Amstrad CPC, and MSX. (The enterprise was a little bit thin on the documentation side - I figured that would be to difficult to do even a lazy port to that bad boy.)

So yea, in light of this - I got the CPC and MSX emulators installed, pasmo should be fine with both these. There was enough documentation and enough info online to be able to do a lazy port. For this title its very basic functionality. Its a matter of getting the memory map for the target, the keyboard routine, and the graphics display. (Like a true lazy/cash grab I might slash the audio component on the ports) Bidabang badaboom two new markets to be disappointed.

Boxart - because these things have to oversell/promise and critically under deliver.
I was thinking something along the lines of..
Image
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

ZX-Paintbrush will save the graphics in this format, with the Export function. Was it you that was saying in another post you were on linux, and couldn't get ZX-Paintrush to work under Wine?

However - looking at the libzx code, it's just expecting 6944 bytes of a SCREEN$. Most assemblers have a binary include directive. In pasmo for example, it would be

Code: Select all

incbin "myscreen.scr"
http://pasmo.speccy.org/pasmodoc.html#dirincbin

Just replace the entire block of db directives with this, or the equivalent in your assembler.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Seven.FFF wrote: Wed Jan 03, 2018 4:43 pm ZX-Paintbrush will save the graphics in this format, with the Export function. Was it you that was saying in another post you were on linux, and couldn't get ZX-Paintrush to work under Wine?

However - looking at the libzx code, it's just expecting 6944 bytes of a SCREEN$. Most assemblers have a binary include directive. In pasmo for example, it would be

Code: Select all

incbin "myscreen.scr"
http://pasmo.speccy.org/pasmodoc.html#dirincbin

Just replace the entire block of db directives with this, or the equivalent in your assembler.
:D Thank you very much, this worked a treat!
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

Sweet. BTW I think doing the board as a background is sensible.

This is the only downside of using a library - it relieves you from the blood and tears of figuring everything out from first principles... then you just have the blood and tears of figuring out the arcane features of the library!! Hang on in there though. If you've got this far this quick it will all come together pretty quickly :)
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Seven.FFF wrote: Wed Jan 03, 2018 5:06 pm Sweet. BTW I think doing the board as a background is sensible.

This is the only downside of using a library - it relieves you from the blood and tears of figuring everything out from first principles... then you just have the blood and tears of figuring out the arcane features of the library!! Hang on in there though. If you've got this far this quick it will all come together pretty quickly :)
I looked at the previous chess programs on the spectrum and a few used the same colour scheme. Agree about the library - that saved a lot of work, plus its nice to have the library code to look at and figure out how someone else got it to work. But you are right - in using the libraries you just transfer the pain of actually grinding out your own solution to a later date where the library can't help you for whatever reason.

The next logical step is to place my pawn sprite on the screen. Once I got that down I will work on the rest of the chessmen. Will also see how much text I can fit along the right hand side... For this I will do it on my Jim Jones first. Once I have satisfied myself I can place graphics willy nilly all over the place I will probably use the fancy library routine that has masking and a whole host of other goodies that would make animation a bit more presentable.

Get the basics straight first then go with the libraries unless I get stuck or its going to take a crazy amount of time to do it alone. And with the sprite/graphics is well worth having a good understanding from the jump start otherwise it seems you are just storing up hurt for later if you don't understand it.

I guess to summarize - libraries are great until you hit a wall and they fail you then you are in just as much a pickle as when you started :D
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 4: (361 days left)

To do a sanity check if my screen layout was ok I did the following... added a bunch of strings on the screen to see if it looked ok..

But the characters seem all borked, I don't understand what has happened.

Image

here is the program code...

Code: Select all

; This program is modified from an example in libzx by Sebastian Mihai, 

main: org 33000					; stay above ULA-contended memory
	jp start					; jump to the beginning of our program
	
	include "libzx/libzx.asm"	; include the libzx library

	stack ds 512				; reserve some bytes for our stack
	endstack:					; mark end of our stack
	
	background_definition:
		incbin "crapbkg.scr"	; the background data is in this file
	
start:
	ld sp, endstack				; set up our new stack (we point to the end 
								; because the stack grows into lower addresses)
	call initialize_libzx		; initialize the libzx library
	
	; this is where the example begins
	
	ld hl, background_definition
	ld de, backgroundVideoBuffer
	call copy_buffer_to_buffer		; copy background definition to 
									; libzx's background buffer
	
	call copy_background_buffer_to_video_ram ; copy libzx's background buffer

player_log:
	ld a, 2
	call 5633
	ld de, string
	ld bc, eostr-string
	ld de, infostring
	ld bc, eostr-infostring
	call 8252
											 ; to the video ram
infinite_loop:
	jp infinite_loop			; lock CPU

infostring: defb 16, 2, 17, 0, 22, 21, 9, 91,32,69,110,116,101,114,32,87,104,105,116,101,32,109,110,118,101,46,32,93 
string:  defb 16, 3, 22, 3, 21, " d2- d4,"
	defb 22, 4, 21, " e2- d4,"
	defb 22, 5, 21, " f2- d4,"
	defb 22, 6, 21, " g2- d4,"
	defb 22, 7, 21, " h2- d4,"
	defb 22, 8, 21, " a2- d4,"
	defb 22, 9, 21, " b2- d4,"
	defb 22, 10, 21, " c2- d4,"
	defb 22, 11, 21, " d1- e3,"
	defb 22, 12, 21, " g1- f3,"
	defb 22, 13, 21, " d2- d4,"
eostr:	equ $
	
end main
I must have screwed up when drawing the background. I will redraw the background and see if that makes any difference later.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Crap 0.1 first assembly project

Post by R-Tape »

Does copy background to videoram set HL, DE, BC in the routine? If BC is more than 6912 it will do the screen but then carry on & spunk data all over the system variables - including the fontseed (23606/7) which should be 0,60.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

R-Tape wrote: Thu Jan 04, 2018 5:55 am Does copy background to videoram set HL, DE, BC in the routine? If BC is more than 6912 it will do the screen but then carry on & spunk data all over the system variables - including the fontseed (23606/7) which should be 0,60.
I will check now.

This is the tap file.

https://nofile.io/f/EC5xmrueVJy/test5.tap

I can't break the program to peek at the memory locations requested...

These are the libzx libraries for the bitmaps.asm..

Code: Select all

;------------------------------------------------------------------------------
; This file is part of the ZX Spectrum libzx library by Sebastian Mihai, 2016
;------------------------------------------------------------------------------

;------------------------------------------------------------------------------
;
; Aggregates all bitmaps and bitmap buffer (background, screen) routines
;
; There are duplicate routines targeting the background buffer and the screen
; buffer. The reason for duplication is performance.
; 
; +-------------------+
; |                   |
; | background buffer |-----
; |                   |     \         +--------------+
; +-------------------+      -------->|              |
;                                     | video memory |
; sprites drawn directly ------------>|              |
; to video ram, appearing             +--------------+
; in "front" of the background
;
; Copying a chunk of the background buffer to the video memory, followed 
; immediately by drawing a bitmap directly to the video memory achieves
; "movable" sprites that don't "erase" the background when they move.
;
;------------------------------------------------------------------------------

	;--------------------------------------------------------------------------
	; Constants and data used by all bitmap routines
	;--------------------------------------------------------------------------
	VISIBLE_VIDEO_MEMORY equ 16384	; start of the video ram
	VIDEO_SEGMENT_SIZE equ 2048		; size in bytes of a third of a screen
	VIDEO_SEGMENT_LINES equ 64		; horizontal lines in a segment
	VIDEO_ATTRIBUTES_SIZE equ 768	; size in bytes of the attributes area
	VIDEO_TOTAL_SIZE equ 3*VIDEO_SEGMENT_SIZE + VIDEO_ATTRIBUTES_SIZE
	VISIBLE_ATTRIBUTES_MEMORY equ VISIBLE_VIDEO_MEMORY + 3*VIDEO_SEGMENT_SIZE
	
	; used to look up video memory addresses in the background buffer
	video_memory_Y_lookup_background ds 192*2
						; reserve 2 bytes for each of the 192
						; possible screen Y values
	
	; used to look up video memory addresses in the video ram
	video_memory_Y_lookup_vram ds 192*2
						; reserve 2 bytes for each of the 192
						; possible screen Y values

	; the background buffer is used to keep sprites from "erasing" the space
	; behind them as they move
	backgroundVideoBuffer:
		videoBufferPixelData ds VIDEO_TOTAL_SIZE-VIDEO_ATTRIBUTES_SIZE
		videoBufferAttributeData ds VIDEO_ATTRIBUTES_SIZE, %00111000
		
	BUFFER_TO_SCREEN_OFFSET equ VISIBLE_VIDEO_MEMORY - backgroundVideoBuffer

	;--------------------------------------------------------------------------
	; Includes
	;--------------------------------------------------------------------------
	include "libzx/bitmaps/bitmaps_vram.asm"
	include "libzx/bitmaps/bitmaps_background.asm"
	
	include "libzx/bitmaps/bitmaps_vram_or_masked.asm"
	include "libzx/bitmaps/bitmaps_vram_or.asm"
	include "libzx/bitmaps/bitmaps_vram_xor.asm"
	include "libzx/bitmaps/bitmaps_vram_not_and.asm"
	
	include "libzx/bitmaps/bitmaps_background_or.asm"
	include "libzx/bitmaps/bitmaps_background_xor.asm"
	include "libzx/bitmaps/bitmaps_background_not_and.asm"
	include "libzx/bitmaps/bitmaps_background_or_masked.asm"

	include "libzx/bitmaps/bitmaps_buffer.asm"
	include "libzx/bitmaps/bitmaps_utilities.asm"
	include "libzx/bitmaps/bitmaps_colours.asm"
so its just loading a bunch of other files... the ones I think its using is the top two vram and bitmaps background...

bitmap_background.asm

Code: Select all

;------------------------------------------------------------------------------
; This file is part of the ZX Spectrum libzx library by Sebastian Mihai, 2016
;------------------------------------------------------------------------------

; Meant to be called before any sprite functionality is used, 
; it initializes sprite routines, including:
;     - pre-computing video memory addresses for each horizontal line
;
initialize_bitmaps:
	; pre-compute video memory addresses for each of the 192 horizontal
	; display lines
	; each stored address is of the first byte of each line (which represents
	; the left-most 8x8 pixel square of each line)
	
	ld b, 0				; we zero out B because C is enough for 192 lines
	ld c, 0				; this will be our counter, going from 0 to 191
	
compute_video_memory_Y_loop:
	push bc
	
	ld l, c
	call get_video_Y	; get address of line in L (returned in HL)
	
	ld d, h
	ld e, l				; DE := address of first square on B horizontal line
	
	pop bc				; get_video_Y destroys B and C, so restore them
	ld hl, video_memory_Y_lookup_background
	add hl, bc
	add hl, bc			; HL := video_memory_Y_lookup + 2*(current Y)
	
	ld (hl), d
	inc hl
	ld (hl), e			; (HL) := word DE
						
	inc c
	ld a, c
	cp 192
	jp nz, compute_video_memory_Y_loop	; if C != 192, compute video memory
										; for next horizontal line down
	ret

	
; Given a screen Y coordinate, calculate the video memory address
; which represents the first pixel on that line.
; 
; Input:	
; 		L - screen Y coordinate
; Output:
; 		HL - video memory address of beginning of Y line
get_video_Y:
	; where y is the screen coordinate in each sector
	;
	; since the 192 pixel tall screen is divided into 3 sectors,
	; then each sector is 64 pixels tall
	;
	; MEMORY Y = (beginning of screen sector) + ( y/8 + 8*(y%8) )*32
	;          = (beginning of screen sector) + ( y>>3 + 8*(y AND 7) )*32
	;          = (beginning of screen sector) + ( y>>3 + (y AND 7)<<3 )*32
	;          = (beginning of screen sector) + ( y>>3 + (y AND 7)<<3 )<<5
	ld e, l			; E := overall screen y (we'll need this later)
	
	ld h, 0			; y coordinates are between 0 and 191, so 
					; they don't need register H
	
	ld a, l
	and 63			; A := y (in sector, since sectors are 64 pixels tall)
	ld l, a			; L := y (in sector, since sectors are 64 pixels tall)
	
	and 7			; A := y AND 7
	sla a
	sla a
	sla a			; A := (y AND 7)<<3
	
	srl l
	srl l
	srl l			; HL := y>>3
	
	ld b, 0
	ld c, a			; BC := (y AND 7)<<3
	add hl, bc		; HL := y>>3 + (y AND 7)<<3
	
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; HL := ( y>>3 + (y AND 7)<<3 )<<5
	
	ld bc, backgroundVideoBuffer
	add hl, bc		; HL := VRAM BASE + ( y>>3 + (y AND 7)<<3 )<<5
	
	; now, depending on where the initial screen y value puts us
	; (which of the three vertical screen segments),
	; offset the memory y location we're returning
	;
	; since there are three segments, we can offset at most by two
	
	ld bc, VIDEO_SEGMENT_SIZE ; we'll offset each time by this much
	
	ld a, e					; A := screen y
	sub VIDEO_SEGMENT_LINES	; A := A - lines per segment
	jp M, get_video_Y_done	; no left over lines
	add hl, bc				; offset by one screen segment
	sub VIDEO_SEGMENT_LINES ; A := A - lines per segment
	jp M, get_video_Y_done	; no left over lines
	add hl, bc				; offset by a second screen segment
	
get_video_Y_done:
	ret
bitmaps_vram.asm

Code: Select all

;------------------------------------------------------------------------------
; This file is part of the ZX Spectrum libzx library by Sebastian Mihai, 2016
;------------------------------------------------------------------------------

;------------------------------------------------------------------------------
; These routines operate directly on the video ram.
; They are meant to draw foreground items, such as sprites.
; They are called right after the background buffer is fast-copied to the
; video ram.
;------------------------------------------------------------------------------
	
; Meant to be called before any sprite functionality is used, 
; it initializes sprite routines, including:
;     - pre-computing video memory addresses for each horizontal line
;
initialize_bitmaps_vram:
	; pre-compute video memory addresses for each of the 192 horizontal
	; display lines
	; each stored address is of the first byte of each line (which represents
	; the left-most 8x8 pixel square of each line)
	
	ld b, 0				; we zero out B because C is enough for 192 lines
	ld c, 0				; this will be our counter, going from 0 to 191
	
compute_video_memory_Y_loop_vram:
	push bc
	
	ld l, c
	call get_video_Y_vram	; get address of line in L (returned in HL)
	
	ld d, h
	ld e, l				; DE := address of first square on B horizontal line
	
	pop bc				; get_video_Y destroys B and C, so restore them
	ld hl, video_memory_Y_lookup_vram
	add hl, bc
	add hl, bc			; HL := video_memory_Y_lookup_vram + 2*(current Y)
	
	ld (hl), d
	inc hl
	ld (hl), e			; (HL) := word DE
						
	inc c
	ld a, c
	cp 192
	jp nz, compute_video_memory_Y_loop_vram	; if C != 192, compute video memory
										; for next horizontal line down
	ret	
	
		
; Given a screen Y coordinate, calculate the video memory address
; which represents the first pixel on that line.
; 
; Input:	
; 		L - screen Y coordinate
; Output:
; 		HL - video memory address of beginning of Y line
get_video_Y_vram:
	; where y is the screen coordinate in each sector
	;
	; since the 192 pixel tall screen is divided into 3 sectors,
	; then each sector is 64 pixels tall
	;
	; MEMORY Y = (beginning of screen sector) + ( y/8 + 8*(y%8) )*32
	;          = (beginning of screen sector) + ( y>>3 + 8*(y AND 7) )*32
	;          = (beginning of screen sector) + ( y>>3 + (y AND 7)<<3 )*32
	;          = (beginning of screen sector) + ( y>>3 + (y AND 7)<<3 )<<5
	ld e, l			; E := overall screen y (we'll need this later)
	
	ld h, 0			; y coordinates are between 0 and 191, so 
					; they don't need register H
	
	ld a, l
	and 63			; A := y (in sector, since sectors are 64 pixels tall)
	ld l, a			; L := y (in sector, since sectors are 64 pixels tall)
	
	and 7			; A := y AND 7
	sla a
	sla a
	sla a			; A := (y AND 7)<<3
	
	srl l
	srl l
	srl l			; HL := y>>3
	
	ld b, 0
	ld c, a			; BC := (y AND 7)<<3
	add hl, bc		; HL := y>>3 + (y AND 7)<<3
	
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; shift left one
	add hl, hl		; HL := ( y>>3 + (y AND 7)<<3 )<<5
	
	ld bc, VISIBLE_VIDEO_MEMORY
	add hl, bc		; HL := VRAM BASE + ( y>>3 + (y AND 7)<<3 )<<5
	
	; now, depending on where the initial screen y value puts us
	; (which of the three vertical screen segments),
	; offset the memory y location we're returning
	;
	; since there are three segments, we can offset at most by two
	
	ld bc, VIDEO_SEGMENT_SIZE ; we'll offset each time by this much
	
	ld a, e					; A := screen y
	sub VIDEO_SEGMENT_LINES	; A := A - lines per segment
	jp M, get_video_Y_vram_done	; no left over lines
	add hl, bc				; offset by one screen segment
	sub VIDEO_SEGMENT_LINES ; A := A - lines per segment
	jp M, get_video_Y_vram_done	; no left over lines
	add hl, bc				; offset by a second screen segment
	
get_video_Y_vram_done:
	ret
Is there a straightforward way to load the background without all these library files? I just want to load the binary into the background.

In other news relating to the project, I got pasmo to assemble the msx rom today. So the plan is when I get stuck on one platform i will just bounce between them that will give me something to do when I am stuck on one part I think. While childish I did grin excessively when the "crap chess MSX" loaded for the first time.

Image
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Crap 0.1 first assembly project

Post by Ast A. Moore »

Nomad wrote: Thu Jan 04, 2018 6:14 am Is there a straightforward way to load the background without all these library files? I just want to load the binary into the background.
Jeepers, man, of course there is! Simply LDIR it. If that’s all you need, then what you’ve been doing so far is utter madness. :lol:

Code: Select all

	ld bc,$1830		;length of block to copy
	ld hl,your_screen_file	;source address
	ld de,$4000		;destination address
	ldir			;copy BC bytes from HL to DE
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
Post Reply