what should i write next?

[Cybershark]

Brilliant! Such a great story of your first Beeb memories, Tricky
What was the deal with the resistor on the serial cable? Was that something that would potentially allow connection of two machines?

You could port Doom from the VIC-20 version

Ugh. I don't know why anyone creates these "flat" versions of Doom. If it doesn't have that game's faux-3D level architecture then it's really nothing more than a jumped-up Wolfenstein clone

[tricky]

The resistor was apparently because the beeb signal was "too loud" for some tape machines. It worked fine anyway apart from the os0.1 cassette bug, which cost me lots of versions of code before I swapped my beeb with my cousin who had an OS1.2 issue 7 Beeb, so technically I don't have my original Beeb, but I have had it for nearly 40 years.

[Beebson]

Thank you for explaining the timing bars for me. Your Beeb buying trip story was very interesting. Was it an actual company? I mean did they advertise themselves as a company or had a small company name on their front door or something? Or were they just a bunch of computer buff electricians without a company, just having put their money together to quickly buy lots of Beebs to make money as long as they can? I know many were/are running their companies in their homes, so it´s not surprising, just wanted to know.

Did later model Bs have that resistor built-in or was that signal loudness fixed otherwise?

Do you remember, how much was that resistor offer?

[tricky]

I think that there was a company name on the advert' but don't remember anything on the house.
It was just a residential street, possibly in or around Cardiff and I think it was a Saturday.
Soldering the resistor into the cable was free, so I suspect that they were enthusiasts who wanted people to be happy with their beebs.
I seem to remember something in a B-Bug about it but might be wrong.
I think I remember someone bringing boxes of beebs in from the back of the house as they were selling in the front, but most of the details are lost to me now.

[Beebson]

Thank you, Tricky, for your nice story.

[HHH]

Hi Tricky,

How about a shiny version of the "Robots" game with sprites and the like, where you move around the screen making the Robots walk into each other to create a hole and then try to manoeuvre the rest of the robots into the holes they make. Basically the Robots follow you so that's how you move them. Does that even make sense?

Probably not overly challenging to code, but it's quite a simple and addictive game.

I have c-source code for a fairly basic version of it I can send to you if it's of interest, might make a better explanation of the game that way.

H

[tricky]

If it is the turn based on, it would make a nice little BASIC game, possibly using the GXR ROM to do the sprites.
Probably not for me though

[Beebson]

A simple 4 colour version can be found from youtube, by typing autobots dos. Type minitron vic 20 to find a simplified robotron take. Melted robots have been changed to player´s laserblasts, otherwise it feels nearly the same.

[Diminished]

What was the deal with the resistor on the serial cable? Was that something that would potentially allow connection of two machines?

Soldering the resistor into the cable was free, so I suspect that they were enthusiasts who wanted people to be happy with their beebs.
I seem to remember something in a B-Bug about it but might be wrong.

I can expand on this. The problem was that Acorn had specifically recommended the Ferguson 3T07 recorder as being appropriate for the machine. My dad bought one of these recorders on that basis.

It was indeed a beautiful tape recorder, boasting lots of shiny metal in its construction, which gave a lovely chunky, clunky feel to its controls. The problem was that it wasn't appropriate for the Beeb at all, as (as mentioned) the signal level from the Beeb would overdrive its input stage. This was, needless to say, somewhat embarrassing for Acorn. The resistor was the suggested workaround for this problem.

And yes -- it was indeed mentioned in Beebug:

[fwibbler]

I remember a game my sister and I used to play on the ZX Spectrum and for years I couldn't remember the name.
Going through all my old retrogamer mags recently I stumbled across a brief mention of it.
Bonkers by Procom software.
Must have been a early game as it works on a 16k machine.
I found a video of it on YouTube https://youtu.be/lS23bK-GJLQ

[tricky]

That does look familiar, but there were a lot os speccy games (10K+ iirc).

[tricky]

I am still plagued by being distracted by new shiny things, especially when someone in a podcast says they really love a game!
Can you guess the game from the sound only?
Here are the sound tunes played, well, about half the ones in the game, but this is at the limit of my current encoding schemes (about 1.75K)!
start_music
in_game_music - played at 1/2 volume as it is apparently 50/50 love/hate and is played at three different speeds in game
last_one_sound
stage_clear
monster_moving
extend_sound - will be used for new high-score
bonus_sound
hurry_up_sound
miss
game_over
game_play
The sound chip in the arcade game doesn't have "noise", so I am planning on replacing some of the "effects" with noise based ones.

Any devs out there, 1.75K seems massive for sound, but does it seem reasonable for the sounds on the .ssd.
They are transcoded from the original chip writes (hacked MAME + custom converter) so have more detail than simple notes.

[Pernod]

Can you guess the game from the sound only?

Nope, sounds good but not familiar at all! It has a Universal circa 1982 vibe.

[tricky]

Here is the code that I use to detect SWRAM banks along with the code to copy to it.

I have posted this code before and I would like it to be on RetroSoftware, but I thought that I would post it here in my own thread
It is generated when SWRAM needs to be detected by my game loader generator used by all my games.

501 FOR O = 0 TO 3 STEP 2
502 P%=&2700
503 [OPT O
556.find_swr
557 SEI

558 LDY #15
559 STY &FE62
560 TYA
561.next_val
562 LDX #15
563 ADC #1
564.next_slot
565 STX &FE30
566 CMP &8008
567 BEQ next_val
568 CMP &80,X
569 BEQ next_val
570 DEX
571 BPL next_slot
572 STA &80,Y
573 LDX &8008
574 STX &70,Y
575 DEY
576 BPL next_val

577 LDX #0
578.swap
579 STX &FE60
580 STX &FE32
581 STX &FE30
582 STA &FF30,X
583 LDA &80,X
584 STA &8008
585 INX
586 CPX #16
587 BNE swap

588 LDY #16
589 LDX #15
590.tst_restore
591 STX &FE30
592 LDA &8008
593 CMP &80,X
594 BNE notswr
595 STX &FE60
596 STX &FE32
597 STX &FE30
598 STA &FF30,X
599 LDA &70,X
600 STA &8008
601 DEY
602 STX &70,Y
603.notswr
604 DEX
605 BPL tst_restore

606 STY &70

607 LDA &F4
608 STA &FE30

609 CLI
610 RTS
620 ]
621 NEXT

558-576 try to find 16 unique values that don't occur at &8008 in the SWROMs, these will be written to the bankss and then all read back to see which values won to avoid detecting mirrored banks multiple times - I think this idea came from someone else's code.
559 is actually for the next section to allow writes to the first four bits of the user via, but we have &0F in a register here!

577-587 try to write the corresponding unique number to &8008 in the slot.
579 STX &FE60 - set Solidisk SWRAM index on early boards
580 STX &FE32 - set RAMSEL only on Master and Compact (iirc)
581 STX &FE30 - set ROMSEL, often used by homebrew and some commercial expansions
582 STA &FF30,X - set Watford ROMRAM/2MEG board - write anything

588-605 check if each value in a slot matches the unique one assigned and add to the list if it does using the same writing methods as before
each byte is compared against the unique value stoted in &7x and then after restoring it, &7x is free to store the bank number if required.

606 write the index of the first SWRAM slot to &70 (is all banks are SWRAM, this will be 0, so will effectively point to itself, which is still valid.
If none were found, this will be 16, so number of banks found is 16-?&70 and they &70?(?&70)..?&7F

607-608 just restores the OS selected bank before returning.

Because testing for solidisk boards can confuse an MMC device attached to the user port, causing it to fail the next operation, you need to take account of this after checking.

To have one retry, I use:
10 ON ERROR GOTO 12
11 GOTO 13
12 ON ERROR OFF
13 *LOAD MPatrol

You could omit 559, 579 and 595 if you weren't supporting early Solidisc SWRAM boards.

After deciding which SWRAM banks to use, you then need to use the same mechanism to copy the data from main RAM to SWRAM

504.copy_to_swram
505 LDX &70
506 LDY #0
507.page
508 LDA #15
509 SEI
510 STA &FE62
511 STX &FE60
512 STX &FE32
513 STA &FF30,X
514 STX &FE30
515.loop
516 LDA (&72),Y
517 STA (&74),Y
518 INY
519 BNE loop
520 LDA &F4
521 STA &FE30
522 CLI
523 INC &73
524 INC &75
525 DEC &71
526 BNE page
527 RTS

?&70 contains the SWRAM bank to write to, &71 the number of pages to copy, (&72) the source and (&74) the dest.
Because I call this from BASIC, I re-enable interrupts after each page, just to be polite!

These is another type of SWRAM that requires a different method!
The Watford 12 ROMRAM board only allows its single bank of SWRAM always in bank 14 to be written to by a ROM already on the board and any write from code on the board will be written to the SWRAM.
I usually rely on BASIC to be on the ROMRAM board and load the file into RAM as if I was going to copy it with the copier above but then use a BASIC FOR loop to do the copy X%!&8000 = X%!&3000 or similar.
The other simple option is to try to *LOAD the file at &8000 which will "just work" if the FS is on the ROMRAM board.
I rely on BASIC being on the board, so detect the ROM by using ROM sel to read &8008 from bank 14, EOR it with &FF and write it back with basic, read it again and write the original value back. if the two reads were EOR &FF different (or just different) then BASIC must be able to write to the bank.
I guess I should check that BASIC isn't in a SWRAM bank where ROMSEL is the write select by not doing this if &F4 is 14

PS I also check for the ROM before I start in case it is already loaded or in an actual ROM.

PPS I also check for a B+ explicitly if 12K is enough SWRAM.

[tricky]

Can you guess the game from the sound only?

Nope, sounds good but not familiar at all! It has a Universal circa 1982 vibe.

Right year, but I know what you mean about universal.

[RobC]

Right year, but I know what you mean about universal.

I think I've guessed it but, having guessed it, I think you may have already told me you were working on this! So I can't be sure that I wasn't at least partially aided by prior knowledge!

[fizgog]

I am still plagued by being distracted by new shiny things, especially when someone in a podcast says they really love a game!
Can you guess the game from the sound only?

Good choice for a conversion as the current beeb lookalikes just don't come up to scratch
Would you be looking at the arcade game for inspiration or one of the consoles, as I think the source code of the Atari 7800 version is on the web

[tricky]

I was going to make it based on playing the arcade version as I couldn't find anything about the "AI" or anything else.
I had been put off by the squashed looking screen and GFX, but it actually looks like it plays quite well.
I didn't play it as a kid more than a couple of times so there is a lot for me to learn.
It wasn't until I looked more closely that I realised that the arcade version is 224x288!
I'm planning on squashing the status parts and removing the impervious and as far as I can see pointless top row of the main play area to save squashing the status area so much and it doesn't hurt that it simplifies the logic a little

[fwibbler]

It would be great if you could work your magic on this game Richard.
So few of the ports of it adhere to the arcade games behaviour properly (on any machine).
Cheers!

[tricky]

I was pointed to the 7800 source from "Namco Limited" but I don't know how close that was, except a few "bug fixes" on atariage.
It would be great if someone knew the rules so that I can get them right first time

[fwibbler]

I found this website that has a general walkthrough of the game.
https://www.trueachievements.com/game/D ... kthrough/2

The main omission from the various BBC ports is the ability to kill enemies quickly by 'feathering your attack' as they put it.
So, instead of just holding down the fire button the idea is to hold down your direction key towards it and rapidly press the fire key 3 or 4 times to rapidly expose the pooka or ryka (or whatever they're called).

The above guide goes on to list the various fruit and veg bonuses to be had on each level.

[tricky]

I've started a thread for DigDig viewtopic.php?f=53&t=26548

[BigEd]

And there was me confusing Dig Dug with Mr Do! (aka Mr Ee!) Totally different games apparently, even though one did come out shortly after the other bearing a great resemblance to the first.

[tricky]

Several sites that I looked at claimed that MrDo was a copy of DigDug, but who knows.

[sweh]

Here is the code that I use to detect SWRAM banks along with the code to copy to it.

I don't see, here, any delays to handle "false positives" from flash ram chips. When I wrote my (limited) detection (it just uses ROMSEL) for my RAM manager I had to put a delay loop in between writing and reading because otherwise the flash ram would return the "buffer" value rather than the true value

Code: Select all

\ FLASH RAM chips aren't sideways RAM; they require a special command
\ sequence to cause them to enter WRITE mode.  But they can "buffer"
\ results, so a write to the chip may be read back again and the written
\ value returned, even though it never made it to the FLASH storage.
\ But if we pause for long enough (200us?) then the cache is cleared
\ and stuff works as normal
\ Through experimentation a loop value of #&50 is too low; #&80 seems to
\ work.  Let's double that.

.delay_swr_write
        JSR SWR_write
        LDX #0
.delaylp
        DEX
        BNE delaylp
        RTS

Or am I missing something clever?

[tricky]

You are not missing it, it isn't there, but I think it should return not SWRAM because it writes the values to each of the 16 slots before reading them all back, so if it just got what was on the bus, it would be from the wrong chip unless maybe it gets around all 16 slots and it is still on the bus.
I haven't tried it, but if you have some, try B-type, a recent astro Blaster, recent Moon Patrol WiP, Warlords or the game whose name must not be mentioned

[sweh]

I _think_ what happens with a flash chip (like the winbond w29c020) is that there's a small buffer (128 bytes?) on the chip so it can write data in pages. So if you try and write to 8008 then the page relevant is loaded from flash into the buffer, then the buffer updated. Then after a timeout period the page is written back to flash. So consecutive writes are fast. During that timeout period reads from that page are satisfied from the buffer.

Where things get confusing is if the chip hasn't been put into write-enable mode; the data still gets put into the buffer and reads are satisfied from it, but the "write to flash" part doesn't happen and the buffer invalidated. So there's a small window where a "bad write" (a write where the flash hasn't been put into write enable mode) value appears to be written ('cos the read returns the buffer) but it never persists. My work around is to wait for the tPROG period to expire.

So I unburied the B that has an IFEL RAM/ROM board in it. It's my least used machine and I'd disconnected it from my video switch and it's been used as a dumping ground to rest things on!

I ran the BASIC script above on that machine and on my primary machine, with a BITD Solidisk 2M128 board.

Looking at data from &70

Solidisk board:

Code: Select all

0070 08 01 01 01 01 01 01 01
0070 04 05 06 07 0c 0d 0e 0f

This is correct; there are 8 SWR banks and they are 4,5,6,7c,d,e,f

IFEL board:

Code: Select all

0070 08 44 44 44 44 44 44 44
0078 00 01 04 05 08 09 0c 0d

That's also correct. 8 banks with that weird layout.

So it seems to be correctly skipping the flash slots (2,6,a,e).

I'm now guessing as to why... I think that what happens is you bad-write to a flash page that corresponds to ROM 14 &8008, then you bad-write to the page that corresponds to ROM 10 &8008.. this second write invalidates the buffer and causes the buffered values to be dropped immediately, so when you eventually get to reading back ROM 15 you get the real unmodified data and correctly identify it as ROM. Since you're not doing a real-write (sending the data sequence to enable write mode) you don't need to wait for tPROG to expire and it works properly.

(In my code I read back the same data immediately after writing and so I do get the buffered value.)

This is all a guess, though!

[tricky]

Thanks sweh for testing and thanks for the background info, I guess it still might fail for a 16K chip but I guess they are much less common.

Do you know how long the timeout is?

[sweh]

The programming time may vary between chips. Steve Picton had suggested 200us as the correct value which the winbond specs ( https://pdf.datasheetcatalog.com/datash ... 994_DS.pdf ) suggests may be the TBLC (byte load cycle time); if no new data is received in that window then the "write to flash" cycle starts, and fails. But this is all guessing!

In my testing a simple ".lp DEX:BNE lp" type delay failed if X started at &50, seemed to succeed reliably with &80, so I just doubled it (LDX#0 before the lp).

[tricky]

640 cycles is quite a lot, if have to count what my code does.