Crap 0.1 first assembly project

Show us what you're working on, (preferably with screenshots).
Post Reply
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: Fri Jan 26, 2018 9:13 am 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. :lol:
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.
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.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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. :lol: 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...

Image

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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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.

Image

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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 27: 338 days left.

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

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 8-)

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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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.
:D

All these utilities and streamlining of work flow make work on the actual projects so much easier.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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 :lol: . 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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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 :lol:

Figured some source porn is needed:

Image

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 :lol: 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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Dangerously close to having a native terminal graphics library for gforth that is functionally the same as ncurses. :lol: 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..

Image

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

Image

:lol:

Figured it was...

Image

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.. :lol:

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
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by 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 :lol: Perhaps you can see what is driving the acetic of the tools / proto ide now...

Image

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.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 36: 329 days left

It's day 36 and I just got to the stage where documentation is at a good place. After having a gentle critique that my code was a little bit on the 'WTF is this? what is it doing?' side of the spectrum. (I recalled in college winning an award for obscure C coding.. I kept that mars bar for years after :lol: )

I figured that my current approach of using a wiki was going nowhere fast as frankly I am too lazy to update it. What I wanted was a way that I could write the code at the same time as waxing lyrical about it in the source .. have that source then either compile/assemble/run in an interpreter when I wanted it too or when I needed to read it, use a markdown viewer to show all the information about what the code was doing, along with the code it was talking about.

In a nutshell... literate programming.

To be honest at first when this was explained to me I just though 'ahh sounds like some sort of chin scratcher crap.' but I thought "well give it a go, its got to be better than what your doing now.." and to my suprise it is.

The script is just a humble awk script called blaze. If that wank word / programming wuwu offended you as much as it did me. Then you are on the same page as I was with regards to this.. At this point I nearly clicked off in disgust but thinking that this literate programming stuff might have some merit I stuck with it and turned the other cheek.

Still its the ends not the means .. What this enables me to do is put all of the explanation, ideas and stuff into the actual source document. That way when I forget everything about it then have to come back and try and fix it I just look at the source in a markdown viewer and badabing badabomb I or whoever is handling my estate is going to be able to maintain whatever mess is left of my programming output.

The nice thing about this is because its markdown, most everyone knows how to write it. You can include images, videos, audio whatever takes your fancy. The source now explains the program. Giving the reader the ability to maintain it. It's not documentation - that is something else. The user manual could probably use a good portion of what is inside the source comments but that is a different thing for a different application (teaching people about the application to be able to use it... not to maintain/upgrade it.) I think that is what got me confused at the beginning.

Anyway - this is how the projects are really going to get commented. Hopefully this will make explaining what I am doing in crap-chess much easier and in the noughts and crosses game.

To test this I will use the technique on Noughts and Crosses and see how it goes today.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Quick update,

the literate programming idea worked out well. It produces a nice readable document that makes things much clearer (to me anyway.).

I did a bit of work on crap chess, but to be honest I was a bit burned out commenting the dragon quest clone and noughts and crosses. I needed something else that was not the IDE to spend some time with lol...

So of course the next logical step is to write a z80 forth. - I know I know groan. But hear me out. I figure this is a good way to learn more about the spectrum, z80 assembly and bizarrely sharpen up my forth skills.

A decent version of forth for the spectrum would be pretty sweet. There are plenty of z80 forth all nicely documented and ripe for study. For this I selected the two most prommising candidates. z80 eforth ( 30 machine code routines form the foundation of the system. everything else is built upon words from these 30 routines.) This gives us a slower system overal but its trivial to port. And you can incremententally convert the words to assembly to see what speed impact you get on the system. Its a great way to play and learn.

The eForth is a bare metal forth, it handles everything itself. But it does not have to be that way - there is nothing to stop you using the rom routines where they exist. The advantage here is that you don't have a initial dependence on an OS like the second system I looked at (Camel forth).

This is the base system, Camel forth is the comparison. I use this to compare against eforth. - Camel is designed to be as slick as possible where as eforth was built with portability and as a learning tool. you could optimise it as much as you wanted after. but at the start its pretty slow.

like I said Camel forth z80 is using CP/M and well that is a bit of a problem as we don't have that on the stock zx spectrum (assuming you didn't get a rom upgrade for the +3... hmmmm)

Anyway. The methodology is compare each part of the system - have a play and try and figure out what each is doing and why. and make a value judgement on what one I would use. (or perhaps none at all..).

Code: Select all

; Camel forth z80
NEXT:    MACRO    ; Start of the macro def.
        EX DE,HL    ; Swap the register pairs
        LD E,(HL)    ; Load value pointed to by HL into E
        INC HL    ; +1 to HL
        LD D,(HL)    ; Load value pointed to by HL into D
        INC HL    ; +1 to HL
        EX DE,HL    ; Swap the register pairs
        JP(HL)    ; Jump to next word pointed to by HL
        ENDM    ; End of the macro def.
This assembles the 'NEXT' code in-line. You need a NEXT for every word you have. This is the most fundamental atom of the operating environment. Every forth word has this little blighter.

Now the issue with the code I have is its designed to work with CP/M that is no big deal as really its only using CP/M to handle the boot sequence, keyboard input and screen management. This can totally be implemented using the Spectrum rom routines but to be honest I probably will just write my own subroutines for this. That said as a quick start using the inbuilt rom routines makes a lot of sense then just phase them out as I write my own routines.

As a learning exercise its pretty fun. The whole source is 6k.

I am looking at two separate implementations to compare and contrast how each author handled each stage. because of this its a great way to figure out how to approach the problem myself. I should have thought of this before...
User avatar
Seven.FFF
Manic Miner
Posts: 736
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Crap 0.1 first assembly project

Post by Seven.FFF »

Do you ever sleep??!

Do you have an original Jupiter ACE? I missed the chance to get one when they were only a few hundred pounds, sadly. Did you know the team behind TheC64 are planning a modern remake (and also for the SAM Coupe)?

I used to have the Leo Brody book, that was great, especially the illustrations.
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: Mon Feb 05, 2018 6:32 pm Do you ever sleep??!

Do you have an original Jupiter ACE? I missed the chance to get one when they were only a few hundred pounds, sadly. Did you know the team behind TheC64 are planning a modern remake (and also for the SAM Coupe)?

I used to have the Leo Brody book, that was great, especially the illustrations.
Lol yes but admittedly last night not so much. :lol: The Jupiter ace, I never got to see one. I don't think I ever saw one on the flesh they were fairly rare beasts. Would have been cool to have one though. At the start of the 90s there were so many of the micro computers you could pick up at boot sales and charity shops I got to have a go on the majority of popular models but I never got to play with the Ace.

Not sure about the modern machine, looks interesting. The big news for me was being told that A. a lisp OS that runs on real hardware, in 2018 has been created and that B. One guy wrote it. :lol: He also managed to port a bunch of libraries that previously were so difficult nobody considered it practical. Haha to say I was floored is understatement. I saw videos of the lisp machines and the gui from the 80s and it was awesome to think that a guy did something like that on modern hardware by himself is just stunning. Everything in lisp... from the ground up. Not using a linux base... not some cheesy emulator. :o

Hmmm So yea for me the more interesting project would be to get a forth machine running on bare metal 64 bit processors with TCP/IP stack, file support and gui would be a more wow proposition. :lol: Starting on the spectrum - a target that already had Camel forth ported to it in the past seems a good start. the Z88 already has a stable version.

I guess what makes me wonder about these modern remakes of the old systems is why not have somthing like a pentagon where you push the limits of the design and see where it goes. or replicate the orignal perfectly. A lot of these projects seem to fall somewhere in the middle. And the expense - its still cheaper to get an original in many cases. That's what makes me think its better to spend the effort building a system on a modern cpu (in the case of lisp/forth machines) and getting all that power with none of the bloat. The ability to go in and change anything you don't like. to be able to drill down to the bare metal and tinker that is really something else.

The nice thing about the 8 bit machines is you are walking the path travelled by many. eforth & camel forth have so much work already on multiple platforms it makes studying how it was done way easier. Plus the processor & architectures of the 8 bit machines is so much more friendly than trying to figure out 64 bit systems with black holes of documentation :lol:

Yea I read Leo B book, his second is also good Thinking in Forth https://archive.org/details/thinking_forth. In fairness to the Forth authors its rare you find a bad book about forth. Even the Fig Forth books for the micros are pretty kick ass. The documentation for the language is solid - the Forth encyclopaedia is one of the best examples of a documented language I can think of every word is diagrammed and explained. Real time forth is another good book I liked very much hmmm I will get the list haha. The only (forth) books I have not read are by Dr Ting. They were supposed to be something else but he still sells them on his website for $35 a piece so I don't want to knock the guys hustle lol to be selling a bunch of books from the late 70s still nearly 50 years later is kinda mind boggling.

oh..

p.s

SAM Coupe was a much better designed system :lol: I'll get me coat.

p.p.s

S100 bus emulation, now that would be a black hole of a project right there. The amount of time I could waste defining custom cards :lol: Its weird it was never emulated.

[youtube]https://youtu.be/DLFIBQ1WlmU[/youtube]

This series is great..
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

To follow up on the NEXT word discussion,

When I read one of the source words, I check it against my copy of forth encylopedia - this was for the 8080 but the principle of operation is going to be close enough for it still to be useful. Plus z80 emulates 8080 so it shouldn't be too far removed (except for the ZXs extra registers and some instructions..)

Anyway - to see what I mean lets look at the flowchart for NEXT. It's one of the most important parts of the whole system. So it makes sense to spend a lot of time here. Because of the decision with Camel forth to in line the code by using the MACRO command. any optimisation you can make to the routine will get propagated every time a forth word is generated/used. The impact of an increase of speed, or reduction of memory is therefore many orders of magnitude larger than one might first think.

It also shows how important seemingly minor choices can be to the whole project. Had this not been in-line code and instead used higher level functions, every single operation in the forth system would have been impacted. It's probably the single worst place to introduce a bug into the system. It literally will get replicated everywhere.

Generally its accepted that in modern Forth's that are concerned with speed that you want to move more towards direct threaded code. Where you are not using it as a learning tool. Yes many older implementations used the indirect technique but that will make the system pretty slow. But if you are looking for a very beautiful and portable system Indirect is a great choice. But you pay for style with speed.

One thing to look at is did the person that ported the 8080 code take advantage of the z80? or was it a lazy port? In the NEXT subroutine/word it makes sense more than any other word to check this.

So later today that is what will happen, a straight comparison between the eForth z80 NEXT and Camel Forth Z80. To start though lets see what the Fig 8080 NEXT word looks like and how its supposed to function..

Image

NEXT is essentially the Forth systems 'Inner interpreter'.

Ok pop pickers, as a sketch eForth is generally going to pick the slower indirect method as the idea is you get the forth system up and running as quickly as possible without a lot of porting of low level assembly. (It only requires the implementer to write 30 subroutines, define the memory map that the program will use and figure out if you want it to be stand alone or work with a existing OS/Rom. That said you can still make eForth faster by making sure that the 30 routines it does go the assembly routine are going to be slick. The other thing is with eForth generally you have lots of options on how to tackle any of the implementation points. You can go with a heavy direct threaded inline approach but the docs warn you about the time its going to take to code the system. Its always going to be a trade off.

Camel forth is taking the Direct threaded, macro approach. And surprise surprise so does eForth. (Well was it that surprising really - this was the one part of the system where you really couldn't compromise for ideological reasons about performance. But we will see looking through the rest of the code that this happens but its more for practical time reasons rather than just because...

Still its intresting to look out for.

For me I am more a fan on how Camel Forth handled NEXT, but your see that eForth is doing some pretty interesting optimisations of its own. (but at the expense of space) Perhaps a hybrid solution might be in order.. I will have a think.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 37: 328 days left

Progress was pretty good today, managed to get fork-exec to work properly in gforth. So now my menu/ide can now execute multiple system applications/tasks and return control to the main program without blocking. :lol: So it now launches relevant pdfs, play sound effects (i like audible cues - ok I admit it I grew up watching knightrider..)

With that issue out of the way I can now get a back to more specy related tasks. doing the literate programming alterations to all the projects is progressing nicely. It makes a big difference to readability and seems to suit my habits better. I should have all three of the spectrum projects commented properly and looking pretty nice by the end of the week.

Arkannoyed's isometric chess was something else to see how a non-potato would go about coding a slick chess program is really something. :lol: I like the idea about encoding data for routines in the actual graphics data as non-display colours. Hopefully I can use that in my own projects as that is a very slick and compact way to handle things.

Besides that spent the day reading documents and trying out various examples in qemu. I had written a boot loader for dos ages ago in college but its been years and my skilz are decidedly rusty. Anyway its not as bad as I remember. Got my bin booting and its all looking peachy. Having got that technical hurdle ticked off can always come back to it later when I want a custom loader for a project. Having qemu makes it so much easier than having to actually do it on a real box.

Image

I found another good source of information - the computer journal was getting referenced a lot in 'Forth Dimension' and it seemed that many of the same authors were writing for both publications. Luckily the full run is on archive.org .

https://archive.org/details/the-compute ... ads&page=2

This newsletter was full of useful stuff - tons of 8bit info, listings and informative articles. One great series is by Brad Rodriguez in Issue 56, it talks about creating a forth kernel on 8 bit machines and all of the planning stages/considerations. It is a really well written series. I would recommend it if anyone reading this was remotely interested in writing there own forth based system. A lot of the suggestions and hints really come down to 'it depends' so he quite cleverly avoids a lot of the flame wars that went on over direct and intersect threading. (me being tactless, unless there is a sentimental reason or some bizarre cpu issue (like having a crippled instruction set) would seem to me direct threading is the way to go. unless you are really pressed for time.)

To sum up cant really complain about today, got the dos boot loader written, got off to a good start with the z80 forth and found some cracking techniques to use for the z80 game projects. Finished my menu launcher poor mans IDE to help write even more tools..


Overall a good day.

Some spoilers for tomorrow - Camel forth z80 without the CP/M :lol: in fairness this was no where near as bad as I first predicted. To walk a well worn path is indeed a pleasure.
User avatar
Morkin
Bugaboo
Posts: 3251
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: Crap 0.1 first assembly project

Post by Morkin »

Nomad wrote: Mon Feb 05, 2018 7:51 am Day 36: 329 days left
This is going to be a very long thread... :lol:

Nomad wrote: Mon Feb 05, 2018 7:51 am It's day 36 and I just got to the stage where documentation is at a good place. After having a gentle critique that my code was a little bit on the 'WTF is this? what is it doing?' side of the spectrum. (I recalled in college winning an award for obscure C coding.. I kept that mars bar for years after :lol: )
I wonder what would have happened if Speccy games programmers back in the 80s had followed the 'clean, tidy and well documented' code mantras of today. I suspect the archive would contain about 50 games... ;)
My Speccy site: thirdharmoniser.com
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: Tue Feb 06, 2018 10:43 pm
Nomad wrote: Mon Feb 05, 2018 7:51 am Day 36: 329 days left
This is going to be a very long thread... :lol:

I wonder what would have happened if Speccy games programmers back in the 80s had followed the 'clean, tidy and well documented' code mantras of today. I suspect the archive would contain about 50 games... ;)
Lol I am sure to the 1-2 other people that read it it must feel like an eternity already. :lol:

I thought the whole documentation thing was BS also, until I would come back to my work and find myself having to figure out what I had done before and having no idea. A lot of time I would just rage quit and start afresh. :lol: cursing my ancestors for not writing down why i had done such and such. Or how to use this tool.

It takes a bit more time, but what I found helps is imagining I am explaining to a knuckle dragger how to do it. then just write it down in the comments. Nice thing about that markdown documentation is you can add cool stuff like video links, photos ect in the comments. And if you are super lazy people demand a manual you can just kick back and say 'oooh its almost ready' :lol: do a slap dash rush edit from the literate programming comments and boom one poorly written manual but done in a fraction of the time it would have otherwise taken.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 39 326 left to go!:

Well despite many potato miss understandings about the spectrum display, things went quite well.

For crap chess, I finished reading the microdrive manual :lol: also found the file library for fuse. So this is looking dangerously close to being a thing. Assuming I have this right I should be able to slurp a regular chess game encoded with standard notation, get the script to encode it into byte format then using the library create a microdrive file.

I still need to go through the microdrive rom disassembly. And figure out how to talk to the thing properly. But I don't think that will be too much of a painful experience (famous last words..)

The one step I forget was I need to use zx7 to compact the data before I create the microdrive... That is an important step. I will also need to have the decoder in the main code blob. (I can see myself forgetting this and then wondering why its all garbage coming from the microdrive :lol:

Noughts and crosses, going to have some fancy XXXOs lol. Well how pretty can you make a noughts and crosses board.. were see. I got regular tiles down now. But I have been seduced by isometric view game boards :roll:
I figure noughts and crosses should be the simplest board imaginable for this approach. That said being a potato even with a fantastic example in the isometric chess source I will still mess this up no doubt haha. But it should be a good learning experience. In one fell swoop I have made what was the simplest of the projects probably the most difficult because of screen positioning issues with a isometric grid and the need for the Noughts and Crosses to know what V position they now need depending on H pos.

I thought about just rushing it out with a simple layout but I won't learn anything from that. The real value is in pushing myself beyond what I can do now. But I knew I wouldn't be able to handle doing the whole of the crapchess board in this way. Its good to acknowledge gross limitations on skill :D

Moving onto tech demos, I have been looking at generators with interesting properties. For procedural generation what I want it to have a set of subroutines & tables that can give a wide range of choices for near randomness or just interesting sequences to be used in various ways in the projects. What was really useful was having the fibonachi society being such all round nice people and leaving almost all of their research free to anyone to look at. There is over 5 decades of information, techniques just waiting to be used.

This is where things sort of went down a rabbit hole. But in a good way. Assuming I didn't want to model the population of bees (yes that is a Fibonacci sequence.. the males do not require fertilisation. Only the female bees have a father figure.. ) There are other sequences that have interesting properties that can be used on 8 bit platforms either straight or as a map on the sequence. Beyond pisano points, there are lewis numbers, we can do the same thing we did with the pissano points but with the lewis numbers and get a whole new sequence to work with.

But where things get a little nuts is I was using the sequence to generate a music track, and I thought 'jeez these sequences are ok, but I would like a bit more choice without fudging the results..' my maths fairy godmother then gave me the Wythoff Array. While Fibonacci and Lewis numbers do turn up all over the place the sequences are one of many that are possible that have similar properties. With the Wythoff array you can get as many sequences as you can generate with your equipment. (I don't like saying infinite, how can you prove that?)

So yea I have over 5000 of these sequence seeds , More than enough for my needs. I just got done creating the word in forth to generate the sequence from the seed. So when I tested it to make sure I didn't make a potato error I will share it :)

What is the point? Well all these sequences can have a map applied to them of some description (probably modulo) and its that sequence that will be used in the subroutines. For example modulo 7 will generate a sequence of non negative integer values in the range of 0 to 6. That is just what I need for lazy music creation.

But it goes further than that, for things like backgrounds - It would be nice to be able to use a sequence generator to create the table data for the background that was displayed on screen. given that a sequence is always going to run the same way - you can design the background around the sequence output you know is going to come. with a cyclical sequence this is useful because you can have a very complex sequence that would have taken a very large amount of space in memory just use a sequence generator to create the data needed. once you have passed that part of the level you just forget that background data till you need it again. For games where you are just moving forward this is a nice optimisation. But even if you have freedom of movement you would just need a buffer of some realistic amount this would still give you a great saving.

Wythoff arrays are from the late 70s early 80s so its fits time-line wise with the retro computing this would have been cutting edge number theory at the time.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

321 days left!

Spent some time working on my pixel skills and creating better backgrounds :lol: Also went through every book I could find about the Interface I and microdrive.

Image

Probably one to many energy drinks lead me to that point. Still I think it was worth it. :roll:

Annoyingly I was missing the microdrive disassembly book which was the one thing I needed after going through all the others.

At this point though, after reading all the interface one stuff, I was so tempted by the references to interface 2 rom cartridges.

Yea you only get 16 k.. but there is a lot of potential. To be able to pack all of the required routines into the cartridge, then get the rest of the memory to play with.. mmmm...

One thing I don't understand is, why you can't just use paging to make huge Rom cartridges?

Hmmm well time to search archive.org for the interface 2 stuff.

One thing I will say is that the quality of the pan microdrive book was outstanding. It's like the author had thought of all the questions someone who wanted to seriously use the microdrive/rs232 or the net would ask.

A couple of questions come to mind regarding the rs232 port and emulation. could I connect to it via a socket?

Trying to figure out how this stuff is emulated is another thing on the todo list. :lol:

As far as progress on the games goes, well having now 'figured out' how the microdrive works, I can create the crapchess data files and the program that will read them. I already did some tests in basic accessing the drive and it all seems to be ok. Next is to use the microdrive shadow rom directly as I already can talk to it via the RST 8 hooks. But I am thinking I will need to be able to talk to it directly if I went the cartridge route.

Thus the need to get the microdrive disassembly book. :lol:

Actually its probably at the point where I could do with getting a hard copy of both.. time to kill a few trees. The other books I can live with looking up the pdfs but somthing like the disassembly's its nice to have it in a ring binder.

I am really happy with the progress that has been made compared to my last entry I really didn't understand how the file transfer process worked with the interface I, now I do. To be honest its pretty easy once you sit down and read :lol: Even the assembly calls are trivial assuming you use the hooks.

One important thing that came up was my misunderstanding of the speed bottleneck, its not the Interface I that is slow, its basic when it trys to access rs232 or the microdrive. Using assembly I can shift the bottle neck to the device rather than the basic interpreter. Some pretty crazy baud rates are possible on paper but in practice hard to say what the specy will tap out at.. still its interesting.

Getting crapchess to work over the spectrum network would be pretty cool but the basic code limits the connection via rs232 or the net to around 50-150 baud. Still for crap chess its kinda ok But assuming I write the routines in assembly this can then be increased. This is more important for later games that were faster.

Going to find out how the emulation of the spectrum network works with fuse, still this is a logical feature creep as I am already using the interface I to store the game data. Might as well use the net/rs232 to enable two players across the network/modem.

The nice thing about the pan book was it actually had the code for a network game of battleship so I can use that as the template. But its all in basic, the next step is to implement it in crapchess in assembly.

The final step is collecting all of the routines, and support routines - and putting the whole thing on a interface ii cartridge.

I think the learning curve of this last step is quite steep but having done it I would be a much better spectrum programmer.

Just getting the microdrive talking in assembly was a big deal :lol: But after I got it working it was easy. It's just getting the information.

I really want to get the game finished, I just seem to be going by a non-direct route and 'enjoying the journey' It seems every tangent I am taking is improving my potato skills better than If i had just rushed it out. :lol:

Regarding the Interface I, its such a shame that it seems to be pretty well designed but they seem to have really bodgged the last hurdle with the hooks, some of them don't work quite right and it cripples the potential for the microdrive.

I had wondered why you were forever having to use NEW, or for example the weird bug you get with the colours. That could have been fixed were they a bit more careful in the final stages of development. It is a real pitty as there seems to have been a lot of care and thought that went into the design of the device its just that in the last stages they seem to have either got someone else to finish the project or just rushed it.

Part of me was there thinking 'but would it not just be easier to ask the user to insert a new disk?' :lol:

I need to check the plus 3 manual but I don't think it works with interface 1. Weird as the plus 2 and the 128k are fine with it. The greedy fella that I am would love to have both the interface 1,2 and the disk drive. as this would give me the greatest amount of space. Ah well that is a simple thing to google.

Being almost a month and a half in now I am really glad I started, its a lot of fun finding out about all these obscure features and bugs, for hardware I never had a chance to actually buy back in the day (microdrives were way to expensive for a kid). Haha I would look at the magazines and wish I could own the microdrive so I guess that is why it has that mystique.

When we got the +3 the disks were cool, and I pretty much stopped using tapes to store my programs. But because I actually owned it there is not quite the same appeal. (weird right...)

Other things that wasted some time, I went through the Machine code tutor, and that is a very nice program. Its just a shame its rotting in obscurity now. So thinking this was a great injustice I decided to 'liberate' it and so now I have 198+ screens of all of the pages no need to hit space to get to the next screen its all on a bootstrap webpage. :lol:

The annoying interface done away with its way easier to look up the lessons. The simulator you could play with on archive. But were I really to go to town I guess its possible to do in java script. That is a really nice way to learn z80 assembly. More people should get to see it. I wonder why its not on some website already. Once I have the spelling mistakes I made on the template fixed I will find somewhere to upload it.

In addition to that been spending time looking at generators functions.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 45, 320 days left!

Well things are starting to come together, finally got my arse in gear and set up a virtual sd card image so I can start organizing the project files properly. It also makes backups simple as now I just copy and paste the image at the end of the day with a script.

For the curious if you are on arch linux... assuming you want to manually create the virtual card/image. And not depend on some cute gui/tool that you didn't write yourself..

Before you read on and get frustrated, and rage quit. If you are trying to create a bootable card, this is not the poorly written tutorial for you. Sadly this method can't generate bootable images (I know I cried myself to sleep over this feature fail myself the first time..) But for creating regular media images this method works just fine. ( hint your missing the bootloader padawan. )

The way you create a bootable image is a bit esoteric manually and would only confuse the potato's amongst us reading the tutorial who just want a regular card image.

First create the image file using dd, I decided to go for a 4 gig card, that is big enough not to worry about having to use multiple images to store asses and binary files but its also not too big (but in fairness if you wanted to target a 64gig + sd card you just have to bite the bullet and use exFAT.) A lot of this is going to depend on your target. You need to go check the technical documentation on what it can and can't handle, what file system it is expecting, what the maximum card size it can take is. Had I gone for 1gb card image then FAT16 would have made more sense. I guess 4gig is just on that threshold where FAT32 makes sense.

Still you might have a target with older firmware for the sd/micro-sd reader so I will include the options for different sizes. It's just a matter of changing the value used in the dd command but if you are as much as a potato as I was your need some guidance/hand holding. Plus dd is not the sort of command you want to just play around with :lol: (its not jokingly called 'Disk Destroyer' for nothing) In addition for very old device targets you might need to use FAT16.. (I don't know you might be targeting some old school hand held thing..

Yea you can have some pretty large FAT32 cards but past a certain point performance starts to suffer and you really should just go for exFAT (assuming your target can support that).

Going bellow 1 gig switch to FAT16..

Remember exFAT is going to need a slightly different command syntax (don't worry I'll add that as an example just in-case you are reading this from 10 years in the future with a 10tb sd card image..)

You might be really pushing the edge case of life and need to use FAT12 (welcome to 1977) Ok I won't judge you...

32gb card

Code: Select all

dd if=/dev/zero bs=1M count=32768 of=mysd32gb.raw
16gb card

Code: Select all

dd if=/dev/zero bs=1M count=16384 of=mysd16gb.raw
8gb card

Code: Select all

dd if=/dev/zero bs=1M count=8192 of=mysd8gb.raw
4gb card

Code: Select all

dd if=/dev/zero bs=1M count=4096 of=mysd4gb.raw
2gb card

Code: Select all

dd if=/dev/zero bs=1M count=2048 of=mysd2gb.raw
1gb card

Code: Select all

dd if=/dev/zero bs=1M count=1024 of=mysd1gb.raw
512mb card

Code: Select all

dd if=/dev/zero bs=1M count=512 of=mysd512mb.raw
256mb card

Code: Select all

dd if=/dev/zero bs=1M count=256 of=mysd256mb.raw
128mb card

Code: Select all

dd if=/dev/zero bs=1M count=128 of=mysd128mb.raw
64mb card

Code: Select all

dd if=/dev/zero bs=1M count=64 of=mysd64mb.raw
32mb card

Code: Select all

dd if=/dev/zero bs=1M count=32 of=mysd32mb.raw
16mb card

Code: Select all

dd if=/dev/zero bs=1M count=16 of=mysd16mb.raw
(I remember my first sd card for my camera was a 64 meg.. (*wipes tear away..)

Ok now you have a raw file, congratulations - you did it and your system is not borked. (well were assume things went ok because your able to read this..) If not, well you have brought shame to your ancestors - go sit in the corner as your system is restored and try again later. All jokes aside. We can't just run off mounting our new card image, because its not formatted yet. Hold ya horses... to format the card image do the following.

get on your big boy pants - were going in as root. If you don't have root access beg the person that does to complete the following steps...

Instead of mysd.raw use whatever name you used to create the card image.. if you are using a different file format (FAT12, FAT16, exFAT or the various other formats... if you are using them your know what they are..) use that instead of FAT32 obviously. But I am going to assume a simple potato like myself is going to stick to something middle of the road size wise ( >2gb <64gb ) and so FAT32 is going to be what ya need to succeed.

For FAT32 cards

Code: Select all

su 

mkfs.fat -F 32 mysd.raw

exit
For FAT16 cards

Code: Select all

su 

mkfs.fat -F 16 mysd.raw

exit
For FAT12 cards

Code: Select all

su 

mkfs.fat -F 12 mysd.raw

exit
For the big boys...

exFat cards

Code: Select all

su

mkfs.exfat -F mysd.raw

exit
Ok cool the last part is perhaps the most obscure - because of some platform changes that happened back in 2012 to arch. A lot of the guides and tutorials that you will find on the interwebs for Linux will fail you hard in this next step.. most distros have the removable media live in a directory /media/ at the top of the file system.
In arch this is no longer the case fear not for I have shed the tears of frustration and rage so that you don't have too.. It's actually close by.

enter the following.. continue to wear your big boy pants in root. Like before if you don't have root access - beg the person that does to help you with the following step.

1 create a directory called sdcard in your media directory.. this is located in /run/media/<name>/ at the top of your file system. It doesn't have to be called sdcard but as I am the one writing this I got to make some choices right?

obviously when you see <name> look at what your actual account name is on the path.. don't know how to do that.. cut yourself just a little.. not too deep. the pain is the best way to learn. :lol: ok joke don't actually do that...

Code: Select all

pwd
look at the output, drink it all in. ok assuming you are in /run/media/<name>/ you should see something similar but your own systems account. use this instead of <name>... you get it?

next the finale! We mount the newly formatted card.

Code: Select all

su 

mount -o defaults,umask=000 /home/<name>/<folder>/<file>.raw  /run/media/<name>/sdcard/

exit
Ok like before <name> is your login, <folder>is whatever you called the folder you have the card image stored at on your system. <file> is the card image file name. you get it?

Assuming it all went ok.. savour the win, you now have the card mounted and ready for use. When you are done for the day, you can just unmount the image.

Code: Select all

unmount /run/media/<name>/sdcard
Remember to back up your image for safekeeping. at the start of your next session just go through the mount step and you are ready to rock out with your card out :lol:

Having gone through this manually the next logical step is to create your own script to handle the process or if you are of the FORTH persuasion - a set of words to create a tool that will handle the process. (Come on you knew that was coming..) Because I don't know about you but I don't trust myself messing with dd manually at 3am in the morning..

Once we have the script set up or alternatively a shiny new set of FORTH words we are all set to create card images of any size and format we want till our hard drive space runs out.

One thing I should add is that there are some really obscure settings you can use when formatting the image - its best to check the documentation but if your platform is mentioned then use that switch.

Anyway we now have a reliable way to generate images for use in development projects. Someone wants to see what your up to you just upload the image (assuming its a reasonable size / depending on connection speed and storage space that is going vary from person to person but don't be that guy that uploads a 4gb image with only 200mb of data on it.. ) to the net or burn the image onto a real media for them and they can walk away. No annoying searching for files or wondering if paths will work. This saves so much time.

The use case is your friend walks in asks to take your project home to work on, you ask if you can email him the files he then complains about how long that will take, can't you make it easy? you then ask him for his sd card/usb stick. You then promise not to look at his porn stash as you copy your development card image to the drive/card and he walks away happy yet oddly ashamed. And you now spend the next week poking fun at his choice of fetish subtly in front of unsuspecting friends and family. :lol:
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Well project time today was spent backing up my hard drive (boring but if I don't do it the laptop will explode and take all my data with it.) While this was happening got to do somthing I was meaning to finish for ages - setting up atari800 and getting the roms and carts all ready. Why? as far as 80s development machines go its not a bad choice, you could have a 6mb hard disk, ram expansions and lots of software. Lots of fig forth got written on the 400 and 800. My plan is test the high level forth stuff using the atari then when its ready run the definitions on the spectrum.

As it stands with the spectrum, developing natively is a bit of a pita. I have to dick about with tiny memories using the stock machines and if you load forth it leaves you with only 18k to play with. vs 1000k...

I thought about using the pentagon but that has its own issues, but to be fair a very cool machine.

So now I have a fig forth that is fast has a huge memory, this makes working through the old forth journals/periodicals so much easier to follow as there is no need to port the code to the new standard it will work right out of the box.

Probably don't need 1024k but nobody said no to bigger right lol?
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 46, 319 days left!

Got wine displaying at a proper dpi for fonts! :lol: no more trying to strain my eyes to make out the menus.
So that is good.

Project time was spent marvelling at the Corvus disk setup. :lol: It has to be the single best hardware you could get for the Atari. For a developer with the equivalent of 5k usd (in today's money) burning a hole in his pocket this 6mb drive is the business. The wait time to load from the hard disk is comparable to a modern machine.

The widget used the two joystick ports of the atari to get a parallel data bus, (thus the speed).

Internally the drive is split into a bunch of floppy disk sized partitions. But because this is a hard disk, and its always spinning. access times are fast. You just copy across the applications you would usually load via floppy disk and assuming there was no annoying copy protection you couldn't remove. The applications load at a fraction of their normal load times.

No more going for a coffee while the project files got backed up :lol:

I spent the day playing with ValForth - an already fast forth for the Atari, lol now its just nuts. :lol: I thought the openmsx was impressive when you pimped out the emulated systems but its got nothing on this.

Watching Amoeba debug at a speed like it was a threaded application is something else. :shock:

This has a cascading effect as it now means all the time you previously would have waited for disk access, swapping out floppy disks, waited for copies of files that is now gone...

To put it into perspective, I didn't get load times for applications like that till I had windows XP and a bunch of ram.

MSX is now in position 2# for nicest 8 bit dev machine I have ever seen. :lol: (I know what your asking... #3 BBC Micro with the Z80 coprocessor, hard disk, and econet)
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

Got the program launcher working nicely with wine applications, this also has a side-effect that I can now use zxpaintbrush properly :lol:

The atari emulator also runs under wine so that now works with the program launcher one key press and I can launch the 6502 development tools, all running natively on the atari 800 and ready to run.

To get my files out of the atr disks, I have a utility that can extract the files, and pop them back once I have edited them on the pc. This means all of the productivity software and tools for the atari I can now mess with and export simply.

what this lets me do is share assets like the graphics, and listings across platforms simply. I can take my asm files that SevenuP creates and use them in the atari 6502 development box. But if you were really going to be a purist there are a number of pixel editors for the atari. But its easier just to use the same tool for everything I think.

This also means that all my fig forth stuff I can write using the atari then anything decent I can just curl out a floppy disk image then have the utility diddle the files to PC ready to do whatever.

This would also enable me to use the code editor to write assembly for the specy, write to the disk then have the utility diddle the files, ready for the pc to then assemble in pasmo. I do this because I can get better reliability with the atari editor, its faster than sublime text editor and its easier to use. :lol:

I'll add some screen shots later (for those playing along at home.) It just blows my mind that something that was written at the dawn of the 80s still owns an editor that is supposed to be the panacea of dev tools. :lol:

Ok here are the screen shots.

Atari intended this only to be a macro assembler to improve the speed of basic programs. The theory was that users would create subroutines they would call from Atari basic. But due to the fact Atari subcontracted this project out to a pretty kick ass development house they totally over delivered and created a brutally effective application that was used for full blown development of assembly projects. :lol: once the copy protection from the disk had been removed of course...

Image

Image

This was the in house debugger for Atari, it was only recently re-discovered but it has everything you could want. The nice thing is amoeba is tiny, fast and has lots of features. You pair it up with the macro assembler and that is a killer combo.

Image

The third tool Atari Program Editor - This is highly customizable code editor. As you can see I have it set up to have a kind of pigs intestines pink when ASM files are being edited. But you can use whatever colour you like. Its a nice way to differentiate between source files. I really like this feature. Its very fast as you would expect and easy to use. Just like a modern editor. But this one loads in less than a second. And has no slow down, and never crashes. Unlike Sublime editor lol. :lol:

Once I have it completely set up, will have z80 extensions show up as orange, the forth extensions will show up as green and basic as black.

Image

Image

Corvus tools +dos, once you get the hang of the commands its pretty straight forward, the menu is all based from one letter key presses. Its very fast also. This is what really makes the thing shine is you can have floppy applications on the Corvus drive running with almost no delay because the write / read times are so fast.

Image

Image
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 47, 318 days left!

Today was mostly a rest day - good to take a break now and again and re-charge the batteries. That said I still ended up messing around with the Corvus atari box :lol: Trying to figure out the extent of Amoeba's patch capability. But to be honest I was such a potato it was a good way to really learn how to use a debugger :lol: to let you in on a secret I haven't been using one for the spectrum. :lol:

Once I figured out what the thing did, and what I could do I face palmed as many of the errors I had with crapchess could have been traced using zeus (lets not go crazy, fuse's debugger needs a lot of love for it to have similar functionality.). So in a roundabout way I made some progress with crapchess in that I am now comfortable using the debugger features so that should catch a lot of the stupid errors I was making each build.

On the plus side the documentation for the Atari is really solid. You seem to have had more of a market for professional books. So everything is there to create a really slick program it just takes some effort.

But with the added advantage that you have lots of support processors/hardware in a way its like a 6502 MSX. A lot of the headaches you get with the spectrum are taken away and you can be very lazy in programming for the Atari.

I had a look at the 6502 mnemonics and they are not all that bad, the Lance L books are essentially the same across processor families just a straight port. So having read through the z80 book his 6502 book is pretty easy to work through. Though dry, the guy goes through everything and gives you a bunch of subroutines that are functionally equivalent across both processor families.

This is what would need to be done for crapchess, have each of the subroutines implemented in both the z80 and the 6502 - where things start to branch even further is when you need I/O. but that is really the only difference + the memory map for the target.

What I am thinking is have the different targets have there own library. That way I can just compile the version I need to test.

In the case of the 6502 the process its-self is different but its not a crippled cpu like say trying to get the z80 code to port to something like a 4004. I think a 6502 port could be done. Just the question is do you want to make a good port or not to the targets within the family.

For instance, I could have the code mostly use the 6502, and have the bare minimum of I/O code. This would require only some changes to the memory addresses used and stuff like figuring out where screen ram lives, the keyboard buffer. That's it. For a lazy port that is totally viable solution but the game would not take advantage of the target systems support chips. and Would probably be slower than it could have and definitely a lot less flashy. (Looking at you ZX spectrum ports on MSX) lol...

The problem with the MSX is - while its got extremely good system design, and its well documented that documentation is for the most part in Japanese. But in fairness there is a lot of good websites and documents to help its not the same as what you find with the Atari.

I think a middle ground can be taken, for logically designed systems with well documented systems its a lot easier to write the libraries and do the port. Because this is ultimately my hobby, its not like I am getting paid to do this so I will just target the systems I find interesting. I can always do more as the mood takes me.

The Atari 800 is well documented, feature rich and has a lot of tools (cough cough the corvus systems). I will do some tests and see if its as straight forward as the books make out to get the atari to bend to my will. :lol:

Anyway enough wibble, time for some action. :lol:

p.s

I did look at the Beeb, and even (spits) the C64 but it came down to two things.

1. the corvus development system is all kinds of awesome.
2. in the case of the Beeb - a lot of the websites are gone. Stairway to hell is for all intents a pay to play site now (you can pay for other peoples material) and all of the previously free stuff is taken off line. So I was less keen doing a beeb version.. In the case of the C64. Well - Something just made my skin crawl. :lol: Plus while having a larger software base its documentation is not quite at the same level. Plus I don't get the system design. The Atari is pretty logical. Same as MSX.

C64 seems like a bunch of compromises/hacks. In that its a lot closer to the spectrum. So I think it would be harder to make a good port to the C64. That said I will keep an open mind, never say never and all that...

Image

More of the Amobea debugger in action :lol: I think it says a lot about how easy to use a program is if a potato like me can pick it up.
Post Reply