Crap 0.1 first assembly project

[Nomad]

Having slept on the problem, looking at the code afresh and re factoring it. I discovered I was being a dummy. I had zigged when I should have zagged. As was pointed out. I had jumbled up my fancy string length calculations. Assuming anything else equally potato does not crop up (highly likely unfortunately...) Predicting that end of the day will see the noughts and crosses program finished.

These keyboard input routines are getting on my nips lol. The multikey input routine is so flakey sometimes it works, sometimes it does not. there is no predictability other than it wont function reliably.

Then there is the test key, it seems a bit more reliable but then its useless for my task because I need to test 1-9 key at the same time.

is there a reliable, responsive way to do this?

Code: Select all

KEYBOARDINPUT:
       LD HL,LAST_K         ; LAST K SYSTEM VARIABLE.
       LD (HL),0           ; PUT NULL VALUE THERE.
_LOOP   LD A,(HL)           ; NEW VALUE OF LAST K.
       CP 0                ; IS IT STILL ZERO?
       JR Z,_LOOP           ; YES, SO NO KEY PRESSED.
       RET                          ; KEY WAS PRESSED.

MULTIKEY:
; WE WANT TO SCAN KEY 1-9, SO THE FOLLOWING WILL BE USED.

;61438 6, 7, 8, 9, 0
;63486 5, 4, 3, 2, 1
	LD A,0
	LD BC,63438         ; KEYBOARD ROW 6-0/JOYSTICK PORT 2.
       	IN A,(C)            ; SEE WHAT KEYS ARE PRESSED.
	RRA                 ; NEXT BIT ALONG (VALUE 2) = KEY 9.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP9         ; BEING PRESSED, SO PUT COUNTER IN MP9.
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 4) = KEY 8.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP8         ; BEING PRESSED,  SO PUT COUNTER IN MP8.
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 8) READS KEY 7.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP7         ; IT'S BEING PRESSED,  SO PUT COUNTER IN MP7.
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 16) READS KEY 6.
	CALL NC,MP6         ; IT'S BEING PRESSED,  SO PUT COUNTER IN MP6.
	LD A,0
	LD BC,63486         ; KEYBOARD ROW 1-5/JOYSTICK PORT 2.
       	IN A,(C)            ; SEE WHAT KEYS ARE PRESSED.
	RRA                 ; OUTERMOST BIT = KEY 1.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP1         ; IT'S BEING PRESSED,  SO PUT COUNTER IN MP1.
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT ALONG (VALUE 2) = KEY 2.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP2         ; BEING PRESSED, SO  SO PUT COUNTER IN MP2.
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 4) = KEY 3.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP3         ; BEING PRESSED,  SO PUT COUNTER IN MP3
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 8) READS KEY 4.
	PUSH AF             ; REMEMBER THE VALUE.
	CALL NC,MP4         ; IT'S BEING PRESSED,  SO PUT COUNTER IN MP4
	POP AF              ; RESTORE ACCUMULATOR.
	RRA                 ; NEXT BIT (VALUE 16) READS KEY 5.
	CALL NC,MP5         ; IT'S BEING PRESSED,  SO PUT COUNTER IN MP5
	JP Z,MULTIKEY
	RET

KEYTEST:
; MR. JONES' KEYBOARD TEST ROUTINE.

KTEST  LD C,A              ; KEY TO TEST IN C.
       AND 7               ; MASK BITS D0-D2 FOR ROW.
       INC A               ; IN RANGE 1-8.
       LD B,A              ; PLACE IN B.
       SRL C               ; DIVIDE C BY 8,
       SRL C               ; TO FIND POSITION WITHIN ROW.
       SRL C
       LD A,5              ; ONLY 5 KEYS PER ROW.
       SUB C               ; SUBTRACT POSITION.
       LD C,A              ; PUT IN C.
       LD A,254            ; HIGH BYTE OF PORT TO READ.
KTEST0 RRCA                ; ROTATE INTO POSITION.
       DJNZ KTEST0         ; REPEAT UNTIL WE'VE FOUND RELEVANT ROW.
       IN A,(254)          ; READ PORT (A=HIGH, 254=LOW).
KTEST1 RRA                 ; ROTATE BIT OUT OF RESULT.
       DEC C               ; LOOP COUNTER.
       JP NZ,KTEST1        ; REPEAT UNTIL BIT FOR POSITION IN CARRY.
       CCF
       RET

With MULTIKEY I tried resetting the accumulator between port scans, but that does not seem to help much. This is the main keyboard input i was trying to get working.

KEYBOARDINPUT works just fine, always responds and behaves in a predictable way. But then its not performing a particularly demanding task.. It's the one you would expect to work fine.

KEYTEST seems not to be so reliable.

[Nomad]

Figured when the copy pasta failed me it was time to actually use my own coconut and 'roll my own' keyboard input comparator.

Code: Select all

POTATOK:
	LD A,0
	LD A,(LAST_K)
	CP $31		; IS 1?
	JP Z,MP1	; JUMP TO MP1
	CP $32		; IS 2?
	JP Z,MP2	; JUMP TO MP2
	CP $33		; IS 3?
	JP Z,MP3	; JUMP TO MP3
	CP $34		; IS 4?
	JP Z,MP4	; JUMP TO MP4
	CP $35		; IS 5?
	JP Z,MP5	; JUMP TO MP5
	CP $36		; IS 6?
	JP Z,MP6	; JUMP TO MP6
	CP $37		; IS 7?
	JP Z,MP7	; JUMP TO MP7
	CP $38		; IS 8?
	JP Z,MP8	; JUMP TO MP8
	CP $39		; IS 9?
	JP Z,MP9	; JUMP TO MP9
	RET

This works much more predictably than the copy and pasted subroutines. However the only pain in the butt is its not like INKEY$ in that I have to hit the key twice to get a response.

But for now its ok, at least it has limited predictable functionality. Will figure out what is wrong later.

Found out what the problem was, I was calling the KEYBOARDINPUT subroutine directly after the POTATOK subrouitne. (thus accounting for why I was having to hit everything twice..)
Having removed this from the main loop keyboard input responds as expected and is reliable.

[Nomad]

Day 25: 340 days left.

As can be seen by my earlier comments today, POTATOK is working just fine and I can get information from the keyboard. I had been trying for days to get the tutorial keyboard routines to work without much success. I don't know what I was doing wrong there or if it was a case of them being non-portable. (lol wouldn't be the first tutorial that used a non-general routine example and stayed quiet about the fact...)

Anyway all that time wasted when I should have just trusted myself and wrote out my own routine. The funny thing was it worked first time (I just didn't realise it), another keyboard routine was causing the problem. I was using the general key test subroutine as a sanity check earlier in the day and had forgotten to take it out.

Still I think that the CP ladders are not the best solution, I think there is a more elegant approach but this was the simple one.

Once the keyboard input was done, I figured just cheeze this and use UGL characters for the noughts and crosses, its still better than the MSX basic listing at this point meh.. the idea was just to get something working then make it 'beautiful'. So I resisted the urge to break out SevenUP and get sprite happy for the moment.

From this point it was trivial to use the SOUNDFX.ASM file I had from crapchess in the project. I like this part about having the multi-file project. Now it's much more like a real program and it literally took me 1 min to include the file and call the routines. I think in the future this approach will greatly increase my productivity as I can be sure that the routines in the libraries work I just have to call them correctly.

Thus the keyboard input routines that were working all now live in KEYBOARD.ASM. Happily I can now use this in the crapchess with a little bit of work (just add in A,B,C,D,E,F,G,H and the arrow keys and were cooking on gas!)

As far as work flow goes, I tend to do the prototyping of ideas in MSX basic as I find it easer to use than spectrum basic. being able to something working straight off the bat (abet slow). Is good. From there I think about if I can feasibly do this on the spectrum in assembly. Then start figuring out the equivalent subroutines needed and if I already have written or have swiped from others or I will need to find/write them.

With the noughts and crosses the listing was 90 lines of basic, no graphics and just text characters to show the board. Speed wise its got the flicker issue that you find with most basic programs that update the screen.

I thought that with assembly code this could be fast enough to be fixed. and with fancy (er) graphics and some sounds, intro screen to tart it up a bit.

The program logic is an array, when a player selects a position on the board to place the X or the O the computer checks if that location is already occupied. If its already taken, an error is raised and the user is asked to input another choice. This continues in a loop till the program gets a board location that is vacant. It then places the O or X on the screen and records the players value in the array location (1-9).

There can be a maximum of 9 possible moves in noughts and crosses, there are three possible outcomes assuming that the players do not abandon the game.

1. Player A wins, Player B looses. No draw.
2. Player A looses, Player B wins. No draw.
3. Player A looses, Player B looses. Draw. (really this should be a case where A and B cant win..)

The basic listing looks at the array locations and sums them, if a certain magic number is reached it will tell you that a win state has happened (3 in a row). Based upon who has taken the last move tells the program who has won.

e.g

if CURRENTPLAYER = A then if any of the array lines sum to the winning total (3) goto winner section of the code.

This is fairly straight forward to do in assembly, my solution was to just have a series of nine memory locations that can be peeked by the program during run time. every time player A or B puts down a O or X a value is entered into these memory locations (in my program they live at 60001 -> 60009. with 2 being player B and 1 being player 1.

my solution to checking if there was already a value in the memory location is simple I just load the memory location into the accumulator compare it if its not zero then branch to an error state. tell the player they can't place a O or X in that location (1-9) and try again. This can be achieved in the form of a CP block of code with a JP to a error subroutine., then finally just a jp back to the start of the input loop.

The valid location selection is simple, assuming that the memory location that the player selected via keyboard (1-9) is 0, then either a 1 or a 2 is placed into the memory location. This is important as I use the 1,0,2 to determine what to print on the screen during the screen update portion of the program.

1 being an X and 2 being the O. blank space is 0. This is just another CP ladder that checks the memory location 60001 -> 60009 and prints to the screen.

The logic is fairly similar to the basic for checking win states, the memory locations are summed then logic is used (a series of AND and ORs should do the trick). if any of these logic states prove true then the program ends in one of the three ways I described earlier and depending on what state the program is in at the end determines how the screen looks to the user (Player A win screen, Player B win screen, Draw)

At the end of the game - there is a key input if players want to play again they can hit Y or if they want to continue on with their lives without more Noughts and Crosses action they can hit N. This is just another keyboard input routine. Would just be a variation of my POTATO routine (POTATOK3) that only checks for Y or N and berates you if you pick another key outside the range.

The last part is interesting, I plan to crash the machine on exit if user selects N.

There - a design outline for a assembly language noughts and crosses game. The reasons for creating such a think dubious at best but sometimes its best to get something done even if its crap and build up the skills haha. And what was obvious was I needed some more work before I can get crap chess working. But now that the noughts and crosses is nearly complete it makes me more confident in tackling crapchess and being able to complete it also.

Its the subroutines that I can use on the other projects that are the important thing, routines I can use again and again that are guaranteed to work out of the box. My prediction is soon this will enable me to increase my output. I figure there is a tipping point where you have enough subroutines in the bag to create any similar game you want then its just a matter of a graphics swap and some minor adjustment of game logic and you are good to go. With the board games I am only really limited by my lack of ability in scrolling the screen at the moment. If I just focus on non scrolling board games then that presents many hundreds of possible games that can be coded.

Snakes and ladders was one I thought about doing but unless I was going to make the squares very small its not fees able without scrolling the screen. So that is something for later. But boardgame geek has hundreds of games just waiting to a chance in the 'product lineup' lol. I always wanted to see how quickly I could bang out a line of games like this. If someone had a library of routines I think a great many could be created. Its just limited by your time in graphics for the different games. But then once you have a few graphics done its not hard to adapt for a new game. And then its just title screens and the help text.

The board games have been played by generations of people so its already play tested and a big part of the work is done then. While not technically impressive at least its a playable game. Lol.

Card games were something I thought about that are a logical progression from this, but actually they are more tricky with the game logic and you have to keep a larger array of data for each game (52 cards to anything up to something crazy like canasta). That is probably the next step after I have had enough of creating board games. Build more skills in developing game logic and do the card games. Eventually I can use these in creating the games I really want anyway (rpgs lol).

Next target after noughts and crosses to develop skill is ... Battleships. This is a logical progression to the skills developed in noughts and crosses in that we go from a 3x3 array to a 2 x 10x10 arrays. It can be written so that a series of menus control the action and graphics will be fine on the spectrum screen. The input routines can be handled and the game logic is pretty similar to what was used in noughts and crosses.

There is more scope for adding in some ship sinking animations when either player gets hit. This will help develop skills and help polish my handling of various game states/menus.

[Nomad]

For those playing along at home, here is the original MSX basic listing I used as the template for the game.

This is crap game gold, taking a two player game that could have easily been played on scrap paper with better graphics and a more intuitive interface and putting it onto a computer. I love these programs. There is something heroic about the lack of analysis that goes into such a folly. As a testament to that - I took it further and made an assembly language version.

Anyway you can take a look at the base program. The book its from is full of games like this, so its a real treasure of crap games begging to be given the assembly graphics and sound overhaul.

[Seven.FFF]

Which MSX emulator do you recommend? Ideally one that does MSX2 as well.

[Nomad]

Which MSX emulator do you recommend? Ideally one that does MSX2 as well.

openMSX is what I use but I don't really know enough about it to form an opinion there are a bunch of others that you could use.

fmsx is also referenced a lot, but there was a lot of technical documentation with the MSX so the emulation standard seems to be very good. With openMSX you can create your own configurations of MSX machine even ones that did not exist. It handles MSX2 and the MSX2+.

The main thing with openMSX is making sure that you have a manufacturer rom otherwise using the graphics launcher is just a pain because the generic rom does not allow you to use disk images. That sucks as the majority of MSX software is going to be on disk. But its fairly trivial to track down hundreds of manufacturer roms for MSX.

What I did was downloaded openMSX, then catapult (the graphic front end), then went to archive.org and got the TOSEC for MSX and MSX2. Then I realised I needed the manufacturer roms to actually run anything but the cartridges and spent about 30 mins googling. One you have that there are a few books on the net but nothing like the amount that there are for say atari/commodore or spectrum.

But where you loose with the books, you gain with the software - there is a lot available and tons of quality releases.

That said if I was an adult back in the 80s for sure I would have bought MSX, they are so nice to use and it was a common standard so there were lots of peripherals available (especially in Japan). It's a shame they were not more popular in the UK or US. With it being a common standard a lot of the compatibility issues that held up progress with microcomputers would have been avoided.

There are C compilers, Pascal, Forth, Logo, (think there is a Fortran and Cobol version available..). Plus a bunch of assemblers.I have not looked too deeply into it but Zen seems to be ok if you don't mind using a Merlin style program to develop on the platform. I got pasmo to compile roms for MSX. You have hardware sprite support and a bunch of other bios routines that help with making applications, plus openMSX has a nice monitor you can generate stuff like floppy disks on the fly I really only scratched the surface with what it can do.

There are tons of resources if you can read Japanese, there is still more that has never been scanned/loaded up onto the net but its all sat rotting on bookshelves in Japanese thirft stores and book warehouses. I remember seing junk shops when I was over there and they were filled floor the ceiling with crap for the MSX, peripherals, magazines, books, softs. One of the heart breakers was I saw a documentary on MSX over there they were interviewing a programmer and he had the source code listings all printed and in his little office for all these games that has never been preserved or studied. A guys whole store of programs and he didn't think anyone would want to look at it. I'll see if the documentary is on youtube it was pretty good.

[Seven.FFF]

Cheers, that sounds good. I'm looking at porting Metal Gear 1 from MSX2, so at some point I really should get round to running it(!). I appreciate the detailed tips

[Nomad]

no worries, nothing worse than sitting in front of openMSX and wonder why nothing will load.



That was me the first time I tried to run a game on openMSX lol.

That said its not a good day without one programming rage quit

Metal gear is a quality game - would be awesome to see how you got that to run on the Spectrum.

My guess is with the MSX once you nail the memory map and figure out how to talk to the rom its all pretty peachy but the tricky part is trying to overcome the limitations of the spectrum. The MSX gives you a lot of support to do great stuff. I think that is why there is some justifiable distaste for a lot of the spectrum titles that got ported to MSX, they didn't take advantage of the MSX hardware support that would make the games run much faster.

But going the other way, haha well the crap basic games are fine but my god trying to get even close to what it could do with some of the professional titles would be outstanding to even get close on the spectrum.

[Seven.FFF]

I had a FUUUUUUUUU- ragequit with openMSX too. Finally got it running with blueMSX, found an English translation patch, and managed to patch it.

I reaaally wanna use C.Born's wav2ay method to have it say "SNAAAAAAAAKE!!!"

Haven't got very far with it yet, but it'll be a radastan mode game that'll run on the Uno and ZEsarUX (and maybe the Next with some tweaking). I'm still playing around with a game screen graphics conversion workflow, but I got a title screen going.

[Nomad]

That looks sweet, its amazing what can be done with the new libraries. I have been itching to getting round to using the NIRVANA libraries but gotta get the basics down first.

Mind was blown today when I finally figured out I could compress more than screens with zx7 I was like 'if its all data.. then why not level data...' depending on the compression ratios its making a game the size of dragonquest look at least remotely possible with multiloading of location data using the compression. I had been scratching my head for a while trying to figure out how to squeeze a open world into 30k with everything else up until now.

Helped keep crapchess's size down also, the background screen now weighs in at 320 bytes compressed. Might even have enough space for a continuous music track now.

But sure blueMSX is the one you tend to see in the youtube videos talking about msx. I think openMSX has a bit of a steep learning curve but once stuff starts to work its nice.

As a way to save the sanity of people trying to follow along with the various projects I waffle about here in the showcase I decided it was high time to get on the github bandwagon and put all the crap online for everyone to see the hot garbage that is my projects.

With all the source code your be able to have a chuckle at my potato antics and experience first hand the bizarre bugs and blind alley ways my projects inevitably take. any bug fixes or general sanity checks are most appreciated. It's also a good way to guard against my decrepit laptop finally giving up the ghost and taking all my data with it. Should be all set up by tomorrow.

[Nomad]

Day 26: 339 days left.

UNLIMITED POWER!!! <emperor cackle..>

I dug up a few of my old forth notebooks this morning while cleaning out some boxes. It got me thinking this might help organize and streamline my z80 assembly projects. Library's of subroutines are nice but you loose precision and specificity with this approach and the programs eventually become needlessly cluttered with code you don't require for that particular application.

But nobody has the time to hand craft custom libraries of subroutines for each project. That would take too long.. But if the process were automated.. taking a few details about the target project that would enable a custom file full of optimised subroutines for that particular application. It would be pretty kick ass.

FORTH is a great little language, I forgot just how powerful and at the same time weird it can be. Both high and low level. Part of this is driven by me being lazy and not particularly careful in my coding. I make to many mistakes to be hand coding assembly routines all the time. With a generator handling the low level implementation of my projects that would give me a sanity check that I got the basics right while at the same time freeing me up to concentrate on new challenges.

Being able to write something like ..

Code: Select all

: GAMEINTRO              STUDIO-BANNER  TITLE-SCREEN INTRO-MUSIC ?ANYKEY ;
: STUDIO-BANNER     INCBIN-FILE SENDVRAM PLAY-SFX FADE2BLK ;
: TITLE-SCREEN         INCBIN-FILE SENDVRAM PLAY-SFX FADE2BLK ;
: INTRO-MUSIC           LOAD-PLAYER START-MUSIC ;
: ?ANYKEY                   ." SHAZAM! I AM A STUB * ;

...

Checking out the constants list that FFF seven sent my way got me thinking it would be nice if I could have whole blocks of code like this, how much faster cobbling together the projects would be. So I recalled how easy it was in forth to do this. Now I just need to track down a z80 opcode list and I will be cooking on gas. No need to write a whole assembler, all the forth program will do is spit out complete project skeletons with assembly listings ready to use in pasmo or zeus.

One big advantage to doing things this way is things like ports to separate targets become more possible, as long as there is an equivalent technique to achieve a desired effect its not hard to set that up with forth. That would be sweet.

[Nomad]

The tools rule..

A big issue with my development process is my eyesight is not the best so the small fonts that are used in wine and other tools does not make itself so useful. I can't read the small characters.

There are ways round it like zeus I can increase the size of the text inside the editor but not the menus that are handled by wine. It means that when I use the emulators I am taking the equivalent of a knife to a gunfight when trying to do debugging and traces.

Interestingly enough though I can enlarge the fonts on native applications so stuff like sublime editor I can have the fonts all quite large. So at least the text editor works.

This is just a rant, but - why on earth would people write applications with tiny fonts in the first place? It's hard enough to use these tools anyway without making the interface look like a eye test. (to put this into perspective, my font on sublime is 20.. yes I have bad eyesight lol..)

But enough of my moans, good things happened today. I got the first version of my forth tool to glue together subroutines into program source. Looking through my notes I forgot just what groovy stuff could be done. memory dumps on the fly, the language turns a modern platform into something you can play with as if it was a microcomputer/microcontroler.

While I can't figure out the cross assembler that comes with it, like I said its not what I am here to do (while writing an assembler for the z80 would be pretty kick ass, its also way beyond what I can do at the moment - plus why re-invent the wheel?).

What I am thinking to do though is because I can just write binary data where-ever and in whatever way I want. This gives me the ability to create my own spectrum file formats from within the application.

The big advantage with this is I can glue together a bunch of different applications and emulators all in the one place to enable testing, editing, building in one place. That will save a ton of time and prevent a bunch of mistakes.

I could have done it with batch files/scripts i guess. But not to the type of integration that I can now do. Having the memory dumps large enough that I can see them is cool. Next thing is to see exactly how much you can manipulate fuse with command arguments/options/config files.

[dfzx]

But nobody has the time to hand craft custom libraries of subroutines for each project. That would take too long..

...

With a generator handling the low level implementation of my projects...

Aren't you just describing a compiler? You express what you want in a higher level language and the generator turns it into assembly language for you?

[Ast A. Moore]

A big issue with my development process is my eyesight is not the best so the small fonts that are used in wine and other tools does not make itself so useful. I can't read the small characters.

What platform are you on? Do you have to use Wine?

[Nomad]

But nobody has the time to hand craft custom libraries of subroutines for each project. That would take too long..

...

With a generator handling the low level implementation of my projects...

Aren't you just describing a compiler? You express what you want in a higher level language and the generator turns it into assembly language for you?

In a limited way, its not producing machine code though. That said there was no reason why it couldn't do that in the future.

What platform are you on? Do you have to use Wine?

I use arch linux, at the moment I am using a rather old laptop, there is no way it can run windows (well beyond xp I guess.) When I get a new machine I will have it as a dual boot so I can use the windows specific stuff that way. But until then I am stuck with wine.

[dfzx]

When I get a new machine I will have it as a dual boot so I can use the windows specific stuff that way. But until then I am stuck with wine.

No need to dual boot. Create a Winders image in VirtualBox. Any modern machine can run a virtual machine these days, and integration is quite nicely handled with modern software so you can copy and paste, save to the Linux file system, etc.

[Nomad]

Progress was pretty steady today, nothing spectacular but further forward than before so that is ok. I thought I would have been done with the noughts and crosses today but ended up spending more time than I should have playing with zx7 and coding the new tools in forth. Still progress is at a good place with the noughts and crosses so I am not particularly worried.

Seems to be too much text and not enough pretty pictures so...



Now get to use my machine like its 1990 again with a menu list of programs that I regularly use - I hit a key and it launches the program I want. How far we have come lol.

Aside from that I went through the TZX file standard and it seems pretty straight forward, it seems more of a wrapper with meta data for a tap file from what I can see. I have been trying to find the sepctrum standard for the TAP file. Is it the same as the C64? with the 3 different values for long,medium and short tones?

The other standards I have been trying to track down are

spectrum disks - I can't seem to find much info on these. I remember back in the day there was one computer store by the early 90s that had the 3" disks in the south west (Weston Super Mare!) I guess they were never that popular.

The other thing is micro drives, I can't seem to get them to work in fuse. Is there some special configuration I messed up? there are a few magazine disc that were distributed on micro drive that I want to look at but can't. They list as over 700k... if that is true how can I create my own to use to store program data?

What is the simplest file format to generate? What I want to do is be able to write the file on the fly with updated data kinda like pasmo does when it compiles a basic loader with the bin data and the assembly file.

I generated a pasmo file that was just a bare bones project used the tzxbas and had a look at that but the specification seems to be a little out of date on the WOS website.

for the people playing along at home.. here is the skeleton source code for the menu program that I use for the editor and running the applications. You can just add your own applications and obviously change the file names to suit your own projects.

Code: Select all

( MENU SYSTEM - ALL THE PROGRAMS AND TASKS I DO REGULARLY )
( ITS LIKE ITS 1990 AGAIN. )

: EMPTY    s" ---marker--- marker ---marker--- " evaluate ;
: EDIT    s" subl main.fs " system ;
: RUN     s" main.fs " included ;
: ECR     EDIT RUN ;

marker ---marker---

It forms a loop where it constantly drops you back into the forth interpreter so you can run the editor, run the other apps (the system calls are what are used to load the external programs.) This acts like a launcher app for the rest of the system.

Anyway trivial but surprisingly useful.

[Nomad]

Here is another useful photo copyable/printable screen planner. It's from a MSX book but its 192x256 pixels so will work just fine for the spectrum.



The issue you might have is that its not 8x8 squares, so unless your doing full screens its probably going to make more sense to use the 8x8 grids or 16x16.

[Nomad]

Day 27: 338 days left.

Still no Noughts and Crosses or CrapChess but - I now have a fully functional application launcher

Now with a single word access to my projects in the editor, another word to assemble and run in emulator. No more annoying directory locations to remember for the wine applications. Sevenup and Zeus run with one word

The next step is putting the various spectrum native utility's that I use on the launcher, then the sound effects programs and the trackers will run from one word each from the launcher.

The next thing to do is go through all the various applications I have on the system now and put them into the launcher and probably create a little menu listing so I can remember the commands.

[Nomad]

Well today was productive. Like I said earlier I got the application launcher working how I wanted. No more searching for where I placed the programs or remembering command line incantations to get the things to work.

What this also gives is the chance to bring together a lot of utility programs that I had previously downloaded and completely forgotten about. Stuff like spectrum clipart and fonts. All that stuff is now together and ready to be used. All of the great little music utilities all ready to go.

The other big news is I can now import text bas files into tap with the great zmakebas from Derek Bolli. This makes things so much easier than having to wrestle with typing in fuse.


All these utilities and streamlining of work flow make work on the actual projects so much easier.

[Nomad]

Day 28: 337 days left

CrapChess developments...

Finally figured out how to use the microdrive with fuse, again mostly due to me being a potato. It's easy once you have the rom.

Now I just need to figure out how to access the microdrive through assembly...

This would be a significant feature creep but it would be kinda cool to have some recorded games that crap chess could step through and update the board from. With the microdrive giving around 100k a drive.. x 8 would give 800k of storage.

That's a lot of games. If we assume that encoding the move data would take 6 bytes per move, aside so we get 5 bites x 40 (the average number of games a human player takes to play a game of chess..) gives 200 x2 (because we get both players moves) giving 400 bytes per game.

back of the napkin calculations..

lets assume I can't use the whole 100k of the drive, lets be conservative and say 80k..

80 x 8 = 640k

655360 / 400 = 1638 games

That would be impressive if I could pull that off. The beauty of this is its not a time critical operation either so loading the data is no big deal. My plan was to chunk the data to main memory from the micrdrive on a game by game basis (so in 400 byte chunks.)

Not sure about how you use your PC chess programs but I never reviewed more than a few hundred games in years. I guess for a serious player they might find the 1600 of games restrictive but I think for most this would be a killer feature and bring it into the realm of 'not instant regret' software.

From a greed point of view there would have been a strong commercial case to set up the program this way, using different micro drives you could sell the user chess lessons, different master games. Greatly expanding the sales potential for the single main product.

File indexing would be handled by the microdrive itself, so I dont think there is extra overhead there. It would just be a a simple index of the microdrive to look at the games.

the data format for encoding the moves would be as follows.

5 bytes

Code: Select all

byte one :
b0 b1 b2 b3 b4 b5 b6 b7
A0 A1 A2 A3 A4 A5 B0 B1    

A = chess piece id (1-32) 
B = player ID (1 = p1 2 = p2)

byte two (start Position):

b0 b1 b2 b3 b4 b5 b6 b7
S0 S1 S2 S3 S4 S5 S6 E0

byte three (end Position):

b0 b1 b2 b3 b4 b5 b6 b7
E1 E2 E3 E4 E5 E6 M0 M1

byte four (timings):
b0 b1 b2 b3 b4 b5 b6 b7
H0 H1 H2 H3 M0 M1 M2 M3 

byte five (timings cont..):
b0 b1 b2 b3 b4 b5 b6 b7
M4 M5 S0 S1 S2 S3 S4 S5 

Ok so this encodes who moved, where they started, where they finished, what type of move was it (capture, regular, castle, promotion rook, promotion knight, promotion bishop, promotion queen, check, checkmate) Then the final two bytes contain the time data.

With the data in place in a portion of ram a subroutine would just read off the memory offset and use that to update the current board in memory.

There would be some way in crapchess to get a player input to advance the game forward a move. and bam the game updates until the end of the game.

Thinking about this further, compressing the data would result in better space use of the microdrive, without knowing the compression ratio that can be expected from using something like zx7 its hard to say but to be conservative if we could get a 4x compression of the data (giving 2560k) Giving a conservative prediction of 6553 games of a 40 move length if they were stored as compressed data.

That would be interesting to see if it was possible. That would actually be bordering on a decent game database. This is such a cool feature to paraphrase Tom MaGee 'aaggrraa! Gotta have it!'.

Is there any way I can reduce the amount of bits needed to encode the data? How difficult is it to talk to the microdrive using assembly? are the rom routines a pita to use? Are my number realistic?

[Nomad]

Day 33: 332 days left

Internet connection pickle. ..

Well my net connection is cursed, However with the replacement of multiple widgets on the main post things seem to be back in action.

In the interim things were productive.

1. Figured out how to read,write forth block files (a.k.a screens) this is the key to creating the macro cross assembler.

2. created a screen editor, no more manually MOVE input buffers to raw memory areas, has insert, delete, add line. I copied most of the ideas from se (a visual ed).

the whole editor is 2048 bytes. (two screens of memory). it operates completely in ram, until the file buffer is written to disk. - this improves the operating speed of the program and also reduces ware and tear on the hard disk. I am hoping to put all my crap tools onto a flash memory so its important to minimise the writes to flash. (that is the whole point of using blocks - you don't interact with the physical hard disk until its absolutely critical. )

With a more minimal feature set (just insert line, and page navigation) I could probably get it down to 1024 bytes.

I had forgotten just how nice forth is to use. The tools I can make with this will make creating my projects on the micro computers so much easier.

Next am at the stage where I can keep the different file formats for the various spectrum file types (tap and microdrive) I found the tzx format but not the tap or microdrive file format.

But having discovered some utilities for writing micro drives here from one kind soul - shout out to serbalgi . I figure I can discover the file format by examining the utility.

What I am starting to do now is modularizing all of my code snippets that I use for the subroutines, then I will be able to do the copy pasta to a new file with graphics, and a few decisions have a new project generated.

There are a few things I still don't quite understand that I will need to straighten out but this has been a great learning experience - the added advantage of forth is its heavily dependent on stack manipulation to get anything done. In a round about way this should make me a better z80 assembly coder. I am guessing with more use of the stack my programs should get a lot faster.

Another discovery that will help my documentation of projects is Dijkstra diagrams. You can imagine my surprise having completed a software engineering course in the 90s to come across this method a few days ago and realise it never once came up in any of my lectures or books from what I can remember. But its a far superior way of illustrating program flow vs flowcharts.

I had began to become frustrated with the way flowcharts can start to look like a hot mess after a certain level of complexity/length. Especially with jumps, calls its a little confusing. However with the Dijkstra diagrams its a much better way of describing these processes. Everything flows down, you don't have to be looking all over the place when a loop or case occurs.

That said there is very little information about this technique besides an obscure article in an crusty forth users group circular.

You can read the article that sparked my interest here.. http://www.forth.org/fd/FD-V01N3.pdf its on page 30.
I am trying to track down Dijkstra's books/papers to see where the source was for the user-group article.

On to CrapChess, well following the discussion of the data format for encoding games into CrapChess I realised that this would be one area where it would really pay dividends to use a non-native solution to encode the data and then just transfer the binary blob when it was ready to the spectrum file.

Encoding a binary is pretty straight forward, keeping everything organized not so much. To save space information on the games, who played would be kept in a printed binder. This also acts as a kind of copy protection as you need the binder to have any idea what game you are reviewing on the microdrive.

One thing I am curious about is how many files you can have on a microdrive...

Having got the net back I was able to track down the file specifications I wanted,

DSK..

Luckly the waybackwhen machine helped out as the link had been dead for 20 years..

The format is the same used on the Amstrad CPC.

Disk image file format
This document describes the standard disk image format. It has the file extension ".DSK".
Disc Information block
This is at the start of all disk image files. Data for the first track immediately follows the Disc Information Block and is at offset &100 in the disc image file.

Code: Select all

offset	comment

00-21	MV-CPCEMU Disk-File\r\nDisk-Info\r\n
	
	"MV-CPC" must be present, because it is used to identify the
	file as a disk image. It is sufficient to check this to identify
	the file as being a disk image.
	
	\r and \n are control character representations used by C
	programming language. ASCII codes: \r = 13, \n = 10

22-2f	DSK Creator (name of utility that made the disc image)	

30	number of tracks in disk image (40,80,42...)

	Do not rely on this being exactly 40 or 80 tracks. Some disc
	images use the extra storage from extra tracks.

31	number of sides (1 or 2)

32-33	size of a track including &100 byte track information block
	(stored low byte followed by high byte)
	
	All tracks must be the same size.

34-ff	not used (0)

Track Information Block
Each Track Block comprises a Track Information Block and sector data. The sector data is always at an offset of &100 bytes from the start of the track block. The data for the next track in the disc image immediately follows the data for the current track.

The first Track Block is located at offset &100 in the disk image file. The track block starts with the Track Information Block and has this form.

Code: Select all

offset	comment

00-0c	Track-Info\r\n

	This is not essential. DO NOT CHECK FOR THIS. In a early
	version of my disk image creation utility for the Amiga this
	was incorrectly written into the track header.
	
0d-0f	not used (0)

10	Track number (0 to number of tracks-1)

11	Side number (0 or 1)

	Do not bother to check that these are correct. Some disc images
	do not have these correct.

12-13	not used (0)

The following parameters are the same as are used in the format track
command in the fdc.

14	BPS (bytes per sector)

	0 = 128 bytes
	1 = 256 bytes
	2 = 512 bytes
	3 = 1024 bytes
	
	This is used to calculate the sector data offset from the 
	Track Information Block.

15	SPT (sectors per track)

	Number of sectors on this track. (normally 9, at the most 18)

16	GAP#3 (used in formatting, &4e)

17	Filler Byte (byte used to fill sectors, &e5;)

	The two parameters above are not essential.

18-&ff;	sector info list

Sector info

Code: Select all

offset	comment

0	track number (C)      - from FDC "READ ID" command
1	head number (H)       - from FDC "READ ID" command
2	sector id number (R)  - from FDC "READ ID" command
3	sector size (N)       - from FDC "READ ID" command
4	FDC Status register 1 - from the result phase of FDC "READ DATA" command
5	FDC Status register 2 - from the result phase of FDC "READ DATA" command
6	not used (0)
7	not used (0)

General format
Single sided DSK images
Disc Information Block
Track 0 data
Track Information Block
Sector data
Track 1 data
Track Information Block
Sector data
. . . .
Track (number_of_tracks-1) data
Track Information Block
Sector data
Double sided DSK images
Disc Information Block
Track 0 side 0 data
Track Information Block
Sector data
Track 0 side 1 data
Track Information Block
Sector data
. . . .
Track (number_of_tracks-1) side 1 data
Track Information Block
Sector data
Notes
The first track must immediately follow the Disk Information Block.
The sector data must immediately follow the Track Information Block.
The sector data must be in the same order as in the sector info list.
In double sided formats the tracks are stored alternating:
e.g. track 0 side 0, track 0 side 1, track 1 side 0 etc..
To hold different size tracks and different size sectors in a disk image:
Size of one track should be set to the size of the track containing the most data. All tracks will use the same size, but some space will be wasted
All sectors must occupy the same space on a track. Take the sector with the largest data
8k Sectors are stored with 1800h bytes only. This is the maximum usable data on one of these sectors
Calculating Track Position and Sector Data Position
The following equation will give the offset to the Track Information Block for the track you want:

track_offset=(track_number*size_of_track*no_of_sides)+&100+(track_size if the DSK image has 2 sides and a request is made to read side 2) To get the sector data offset:
Make sure the correct Track Information Block has been loaded.
Set a counter to 0
Check the R value in the FDC command against the sector number in the sector info list.
If the value doesn't match then increment the counter.
If the value>18 then the sector doesn't exist.
When the sector has been found, the sector data is calculated as: sector_data_offset=track_offset+(sector_position*BPS)+&100
The size of the sector data to read is defined in bps in the sector info.

[\quote]

Also TAP format this time the page was still running.

The .TAP files contain blocks of tape-saved data. All blocks start with two bytes specifying how many bytes will follow (not counting the two length bytes). Then raw tape data follows, including the flag and checksum bytes. The checksum is the bitwise XOR of all bytes including the flag byte. For example, when you execute the line SAVE "ROM" CODE 0,2 this will result:

Code: Select all

             |------ Spectrum-generated data -------|       |---------|

       13 00 00 03 52 4f 4d 7x20 02 00 00 00 00 80 f1 04 00 ff f3 af a3

       ^^^^^...... first block is 19 bytes (17 bytes+flag+checksum)
             ^^... flag byte (A reg, 00 for headers, ff for data blocks)
                ^^ first byte of header, indicating a code block

       file name ..^^^^^^^^^^^^^
       header info ..............^^^^^^^^^^^^^^^^^
       checksum of header .........................^^
       length of second block ........................^^^^^
       flag byte ............................................^^
       first two bytes of rom .................................^^^^^
       checksum (checkbittoggle would be a better name!).............^^

Note that it is possible to join .TAP files by simply stringing them together, for example COPY /B FILE1.TAP + FILE2.TAP ALL.TAP

For completeness, I'll include the structure of a tape header. A header always consists of 17 bytes:

Code: Select all

        Byte    Length  Description
        ---------------------------
        0       1       Type (0,1,2 or 3)
        1       10      Filename (padded with blanks)
        11      2       Length of data block
        13      2       Parameter 1
        15      2       Parameter 2

The type is 0,1,2 or 3 for a Program, Number array, Character array or Code file. A SCREEN$ file is regarded as a Code file with start address 16384 and length 6912 decimal. If the file is a Program file, parameter 1 holds the autostart line number (or a number >=32768 if no LINE parameter was given) and parameter 2 holds the start of the variable area relative to the start of the program. If it's a Code file, parameter 1 holds the start of the code block when saved, and parameter 2 holds 32768. For data files finally, the byte at position 14 decimal holds the variable name.

[Nomad]

Day 34: 331 days left

Progress on the tools is going great, have my terminal display library almost complete for forth. Now my programs can have boxgraphics, and colour like a poor mans ncurses. Lots of ascii terminal escape codes

Figured some source porn is needed:



The source bellow contains the low level words used to change the terminal colours and inks.
Box graphics build on this as the technique to display the extended characters relies on the escape
string.. I like to think of forth as lego brick programming, you build the program from the smallest useful
components parts possible and re factor till each word is hopefully 3 lines or less long.

It would be more efficient, and less readable for me to just pluck the required colour value from the stack, but that then makes stack management a pain in the butt as I would have to keep track of the parameters I was passing each time I wanted a different colour. Plus its easier to read when you have the words self documenting what they do. I am a simple potato, I know if I try and optimise it too much I will just mess up my stack by leaving values after the word had worked its magic and then that will cause havoc later.

Code: Select all

\ NORMAL BRIGHTNESS (40-47) CLEARS SCREEN.
\ SAMPLE USAGE: 
\ BLACK-PAPER BRED-INK ." HELLO SPECTRUM COMPUTING!" 
: BLACK-PAPER    ( -- )
  $1b EMIT ." [40m " PAGE ;

: RED-PAPER    ( -- )
  $1b EMIT ." [41m " PAGE ;

: GREEN-PAPER    ( -- )
  $1b EMIT ." [42m " PAGE ;  

: YELLOW-PAPER    ( -- )
  $1b EMIT ." [43m " PAGE ;  
  
: BLUE-PAPER    ( -- )
  $1b EMIT ." [44m " PAGE ;  

: MAGENTA-PAPER    ( -- )
  $1b EMIT ." [45m " PAGE ;  
 
 : CYAN-PAPER    ( -- )
  $1b EMIT ." [46m " PAGE ;  
  
 : WHITE-PAPER    ( -- )
  $1b EMIT ." [47m " PAGE ;  
  
\ INKS 30 - 37 REGULAR BRIGHTNESS

: BLACK-INK    ( -- )
  $1b EMIT ." [30m "  ;

: RED-INK    ( -- )
  $1b EMIT ." [31m "  ;

: GREEN-INK    ( -- )
  $1b EMIT ." [32m "  ;  

: YELLOW-INK    ( -- )
  $1b EMIT ." [33m "  ;  
  
: BLUE-INK    ( -- )
  $1b EMIT ." [34m "  ;  

: MAGENTA-INK    ( -- )
  $1b EMIT ." [35m "  ;  
 
 : CYAN-INK    ( -- )
  $1b EMIT ." [36m "  ;  
  
 : WHITE-INK    ( -- )
  $1b EMIT ." [37m "  ;  
  
\ BRIGHT INKS 90 -97


: BBLACK-INK    ( -- )
  $1b EMIT ." [90m "  ;

: BRED-INK    ( -- )
  $1b EMIT ." [91m "  ;

: BGREEN-INK    ( -- )
  $1b EMIT ." [92m "  ;  

: BYELLOW-INK    ( -- )
  $1b EMIT ." [93m "  ;  
  
: BBLUE-INK    ( -- )
  $1b EMIT ." [94m "  ;  

: BMAGENTA-INK    ( -- )
  $1b EMIT ." [95m "  ;  
 
 : BCYAN-INK    ( -- )
  $1b EMIT ." [96m "  ;  
  
 : BWHITE-INK    ( -- )
  $1b EMIT ." [97m "  ;  
  

Still it stops me going mad with boredom looking at the terminal. Damn I wish gforth had a complete gui library would be great to have something like Qt or sdl. anyway enough of my moans.

The screen editor is looking acceptable now, like the screen editors I saw in the 80s forth books. I count that as a success.

CrapChess wise, the tools are ready. Now its just a matter of dumping the data for the chess games. Once that is done, put them onto the microdrives. then test to see if they can be read by the spectrum.

I think that is a good short term target.

Will cook up a little tool to create the index for the games with scribus (the linux desktop publishing/ poor man's in-design.) as I can't bring myself to use LateX. There is a case for just rolling my own pdf but I have done that before and its not as pretty as what you can do easily with scribus scripting. Want to have a retro/early 80s font and border. So am now looking for the IBM selectrex fonts.

This has gotten me thinking of the auto documenter tool I wanted to create before - it would just slurp all of the comments and dump them to a pdf, with this in mind next time i re-factor CrapChess the comments will be written with that structure in mind. (The auto documenters I have seen require some magic strings to be used in the comments to organise stuff when the organizer is building the pdf) This will help with maintainability and will be very useful for the next projects.

CrapChess progress, thanks to the link I was given earlier a whole treasure trove of slick techniques and novel demos were found. I doubt much coding will get done today just me looking for interesting tricks/techniques that might be good for the project.

http://www.pouet.net/prod.php?which=65291

I love stuff like this. to be able to get so much for so little.

Sure some methods are more useful than others but I think its good use of my time to take a look and see what's possible. Especially for things like attract screens or prompts its not needed to have complicated subroutine just to get some attention. If it could be done in a very compact manner (not like my posts) then so much the better.

[Nomad]

Dangerously close to having a native terminal graphics library for gforth that is functionally the same as ncurses. totally by accident I had just assumed that terminal escape strings worked one way when in fact they were way cooler and more versatile. I stared at the screen looking in amazement at what I had done by dumb luck..



This was what was on my screen, but in my mind I saw this..





Figured it was...



Might be overstating things but a native complete ncurses library would be kick ass. that is THE tool.

Sure its not the foreign function interface to SDL that everyone lusts after but before this it was just a bunch of foreign function libraries that were incomplete, broken or both. So with gforth unless you were going to switch to a commercial forth package with a gui with a great deal of junk boilerplate and bloat you were stuck with the default terminal.

until now..

my potato brain quickly realised that the ncurses menus were just on the horizon native, no annoying c-libraries to interface with and compromise with.

Will add in the boxgraphics I was playing with before and badabing badaboom going to be sweet terminal grpahics, with windows. mmmm... very nice.

[Nomad]

Day 35: 330 days left

Cool box graphics are now in, now just got to make windows relocatable anywhere on the terminal and in the words of Allan Partridge 'GOOOOOAAAALL'

The tools are starting to take shape, the overall structure. Talking it through with some smart fellas I got a number of novel ideas that I think will make for a much better final outcome. This whole 'Literate programming' business seems like a wise idea and would force me to adopt practices that I really should have been using in the first place.
I will go back through crapchess and the noughts and crosses and plug this in also. The auto documenter should make for interesting reading (not really but its the best chance for a fully documented complete thing...

A source slurpper is trivial even more so in cough cough ... well you know what.. I did think of doing it in Lisp first but having a massive static binary blob of lisp sitting in the tool chain was not going to fly.. I like Lisp, but the whole idea behind me spending all this time writing these tools is that I have a tiny set of tools that I can put on something crazy like a 1 gig micro sd., Now its true that a static binary probably will take around 50-100mb that soon adds up and when the editor is checking in at around 3-4 kbytes.

The D-Charts that I talked about earlier in the week are also part of the plan, it makes things much easier in explaining words/subroutines using this method.

Looking back I realise this can't be much fun to be reading - its just a bunch of tools and not much game at the moment. All I can say to that is I want to make the best tools I can in a way that I can learn the most from. I don't like bloat tools but that is a personal design choice. I like the challenge of getting something to work in a limited space. (unlike my posts..)

But if you are as much a nerd for tools/utilities as I am perhaps you can relate to it not always being a rational thing .. One of my fav tools ever was Borland turbo C Perhaps you can see what is driving the acetic of the tools / proto ide now...



The rest of the borland programming ide's were similar if you had the chance to use Pascal, Basic or Cobol you would have used the same editor.

Before this I had always just used compilers or interpreters, never as an integrated IDE. I remember being stunned at the concept when I sat down at the pc. I guess its nostalgia for college days but that is the history behind it... For the moment anyway, it will just link to pasmo/zeus if i can figure out how to use the zeus debugger without firing up the gui so much the better.. given all of the cool little utility programs I was made aware of for converting and dissecting the different file formats for the spectrum it seems good to include these also.

If you see what I mean all of these tools will be able to be used from one central location... gradually I can implement them natively but that will take time and effort.. it depends what the trade off is. Being able to forgo the use of wine will give a significant saving of execution time and decrease the overall size of the tool chain. Plus every tool I build I learn so from a selfish point of view it benefits me in terms of know how but at the expense of time. I am not talking about writing an emulator, but the file tools I think its realistic to roll my own. And the benefits of learning the file formats inside out would help later on.