(classic) New target: Bondwell 12/14
(classic) New target: Bondwell 12/14
Yet another CP/M machine.
The Bondwell 12 and 14 models were Kaypro competitors.
The text symbols permit low resolution graphics at 160x75, an interesting sound interface provided a cheap but effective 8 bit DAC, which I hooked to the existing single bit functions ( what a waste ..but the sounds are still nice ).
The Bondwell 12 and 14 models were Kaypro competitors.
The text symbols permit low resolution graphics at 160x75, an interesting sound interface provided a cheap but effective 8 bit DAC, which I hooked to the existing single bit functions ( what a waste ..but the sounds are still nice ).
You do not have the required permissions to view the files attached to this post.
Re: (classic) New target: Bondwell 12/14
grin.. the author would have loved z88dk!
You do not have the required permissions to view the files attached to this post.
Re: (classic) New target: Bondwell 12/14
I thought to extend the existing 4bit wave sound driver of the Commodore 128 to the Bondwell 12 and 14 models.
Just to set some sort of a standard, they are tuned at 8khz, 4 bit packed, unsigned sound data.
I'm still hoping to be able to feed also the 1bit library with the same format 8)
Just to set some sort of a standard, they are tuned at 8khz, 4 bit packed, unsigned sound data.
I'm still hoping to be able to feed also the 1bit library with the same format 8)
Re: (classic) New target: Bondwell 12/14
Thanks for this beautiful new target! All my three programs now support the Bondwell 12/14.
There are however a few issues, you can use my MastermindRK game for testing:
1. games.h virtual joystick input is very slow and therefore pretty much unusable, so I'm instead using standard keyboard input which works fine.
To reprduce this problem, remove the "|| defined(__BONDWELL12__)" condition from this line:
#if defined(__ABC80__) || ... || defined(__BONDWELL12__) // || defined(__GL__)
#define GAMES_H_NOT_AVAILABLE 1
2. Can you somehow hide the blinking cursor? Unlike on other CP/M systems, the cursor doesn't follow the gotoxy() position, so the workaround to position the cursor to a corner of the screen is not available.
3. There are some weird characters in the disk directory behind the program file name. H-Tron and MastermindRK are affected by this, but not EPB. This problem however has no effect on functionality, it just look ugly. ;-)
There are however a few issues, you can use my MastermindRK game for testing:
1. games.h virtual joystick input is very slow and therefore pretty much unusable, so I'm instead using standard keyboard input which works fine.
To reprduce this problem, remove the "|| defined(__BONDWELL12__)" condition from this line:
#if defined(__ABC80__) || ... || defined(__BONDWELL12__) // || defined(__GL__)
#define GAMES_H_NOT_AVAILABLE 1
2. Can you somehow hide the blinking cursor? Unlike on other CP/M systems, the cursor doesn't follow the gotoxy() position, so the workaround to position the cursor to a corner of the screen is not available.
3. There are some weird characters in the disk directory behind the program file name. H-Tron and MastermindRK are affected by this, but not EPB. This problem however has no effect on functionality, it just look ugly. ;-)
Re: (classic) New target: Bondwell 12/14
Thankyou Robert, I was already aware of points 1 and 2 .
The Bondwell2 and Bondwell 12/14 deserve a direct input scanning, at the moment it is using the generic code based on the keyboard input.
I didn't notice the problem of the filenames, which honestly scares me a bit because I'm not sure how to find/ fix the problem. The availability of the COM file permits a manual creation of a valid disk image with comtools, though.
The Bondwell2 and Bondwell 12/14 deserve a direct input scanning, at the moment it is using the generic code based on the keyboard input.
I didn't notice the problem of the filenames, which honestly scares me a bit because I'm not sure how to find/ fix the problem. The availability of the COM file permits a manual creation of a valid disk image with comtools, though.
Re: (classic) New target: Bondwell 12/14
I've had a look at the disc image (in this case mastermind) and I can see where it's come from:
And in a hexdump of the file, this the directory entry that's being displayed:
Corrupt directory listings are usually caused by:
- Incorrect directory size
- Sidedness issues
- Incorrect/missing skew table
- Mismapping between the .dsk sector layout and the actual sector
But most of the time they result in the program not loading, so this one is definitely special!
It's odd, because there's another place (earlier on) that could be construed as a directory entry, but isn't.
The usual way I try to figure this out is:
* Enable the code in cpmdisk.c that is marked "// Code that marks each sector so we can see what is actually loaded"
* Breakpoint at 0x100
* Dump of the memory, and then look at the number patterns.
* Scratch head
* Try something
* Repeat
And in a hexdump of the file, this the directory entry that's being displayed:
Code: Select all
000036A0 00 CD 7A 29 D2 C9 07 21 - 21 00 39 E5 21 54 00 39 ..z)...!!.9.!T.9
- Incorrect directory size
- Sidedness issues
- Incorrect/missing skew table
- Mismapping between the .dsk sector layout and the actual sector
But most of the time they result in the program not loading, so this one is definitely special!
It's odd, because there's another place (earlier on) that could be construed as a directory entry, but isn't.
Code: Select all
00003580 00 39 E5 CD ED 26 7D CD - 9E 29 D1 7D 12 21 4F 00 .9...&}..).}.!O.
* Enable the code in cpmdisk.c that is marked "// Code that marks each sector so we can see what is actually loaded"
* Breakpoint at 0x100
* Dump of the memory, and then look at the number patterns.
* Scratch head
* Try something
* Repeat
You do not have the required permissions to view the files attached to this post.
Re: (classic) New target: Bondwell 12/14
Dom, how did you determine the right value for 'gap' ? Is it extracted from the BIOS tables?
edit: I just noticed that some tool is differentiating between r/w gap and fmt gap. Probably I should have used 12 but 22.. or 23?
edit: I just noticed that some tool is differentiating between r/w gap and fmt gap. Probably I should have used 12 but 22.. or 23?
Re: (classic) New target: Bondwell 12/14
It would have come from cpmtools config or from the output from a Samdisk conversion - generally I didn’t have a problem that needed the value changing.
I think it’s only used by .dsk format as part of the header.
Sometimes it’s easier just to switch to a different format?
I think it’s only used by .dsk format as part of the header.
Sometimes it’s easier just to switch to a different format?
Re: (classic) New target: Bondwell 12/14
I think it might be skew:
Code: Select all
samdisk view disks/bw12/CPM2_2.IMD
[disks/bw12/CPM2_2.IMD]
300Kbps MFM, 18 sectors, 256 bytes/sector:
0.0 0 9 1 10 2 11 3 12 4 13 5 14 6 15 7 16 8 17
Re: (classic) New target: Bondwell 12/14
I've had another look at this and ended up in the cul-de-sac of skew for far too long. Given that the program loads and runs, skew can't really be coming into play.
Looking at the CP/M boot disc I've got I can see that the first used extent is 2, for discs generated by us it's 1.
So, changing the number of directory entries to 128 (from 64), gets us onto extent 2 and hopefully clears up this issue.
Looking at the CP/M boot disc I've got I can see that the first used extent is 2, for discs generated by us it's 1.
So, changing the number of directory entries to 128 (from 64), gets us onto extent 2 and hopefully clears up this issue.
Re: (classic) New target: Bondwell 12/14
thankyou so much for intervening
Re: (classic) New target: Bondwell 12/14
The keyboard
I discovered that the models 12 and 14 have a serial keyboard, no auto-repeat.
The keyboard has no autorepeat, thus, on a keypress a keycode is sent.. once.
No events are generated when the key is released.
Thus, the getk() function gives a positive result only when first time invoked, in some case a game (such as 'microman') can still be adjusted by inserting a correction in the code to cache the last valid read for getk() or joystick() and making them 'sticky'.
Obviously, in that case, the quiet position won't be possible anymore, and joystick() can't be corrected for multiple keys being pressed together in any case.
By the way I found a beautiful piece of history of the Bondwell related code here:
https://secure.eld.leidenuniv.nl/~moene ... gg-keybuf/
It is a good, well commented example on how to create a resident driver on the CP/M, in this case to add a read-ahead keyboard buffer.. sadly useless for the current problem, but we might borrow the Interrupt redirection stuff.. is @Dom interested?
I discovered that the models 12 and 14 have a serial keyboard, no auto-repeat.
The keyboard has no autorepeat, thus, on a keypress a keycode is sent.. once.
No events are generated when the key is released.
Thus, the getk() function gives a positive result only when first time invoked, in some case a game (such as 'microman') can still be adjusted by inserting a correction in the code to cache the last valid read for getk() or joystick() and making them 'sticky'.
Obviously, in that case, the quiet position won't be possible anymore, and joystick() can't be corrected for multiple keys being pressed together in any case.
By the way I found a beautiful piece of history of the Bondwell related code here:
https://secure.eld.leidenuniv.nl/~moene ... gg-keybuf/
It is a good, well commented example on how to create a resident driver on the CP/M, in this case to add a read-ahead keyboard buffer.. sadly useless for the current problem, but we might borrow the Interrupt redirection stuff.. is @Dom interested?
Re: (classic) New target: Bondwell 12/14
Cursor handling and MC6845 stuff are now in.