An OSI C4P Adventure (including fixing a RAM expansion board, enabling for cassette, writing a software demo and lots of other things!) (a 2014 Retrochallenge)

The most recent text is at the bottom. Click here for the summary.

30th June, 2014 (Start)

Greetings. A few months ago I checked out an Ohio Scientific Challenger 4P. This unit had a 527 RAM board fitted which is supposed to boost the memory from 8k to 32k. Note all the 2k static RAM chips!

Challenger Ram expansion board

Figure 1. 527 OSI RAM expansion board

The board doesn't work. It seems that the dip switch is not critical but the mass of jumbled wires in the photo (some of which have detatched from the pins) ARE. These are jumpers which need to be configured to the other memory in the overall computer (8k). I have no idea how to do this and in fact I've made things worse by unsoldering all these wires (not shown) before I really understood what they did!

There might also be bad RAM lurking amongst all those chips.

Oh, one other thing. One of the logic chips was inserted the wrong way around!

Anyway, my retrochallenge is to get this board working which will give my C4P 32k RAM. Also, (if time allows and in case it's easier than I think it's going to be) I'd like to wire up a cassette interface to the C4P and successfully write and load in WAV files from my PC.

1st July, 2014 (progress post 1)

How to wire the jumpers?

The first thing was to drag out the board and get back to where I was when I first checked it out. I had discussed this board with others on the Vintage Computer Forums in the past. I read that thread and checked the documents I had. Problem is, I have no manual for this particular board!

As I mentioned above, I'd removed the wires over those jumper pins and now had the bare metal (Figure 2).

OSI 527-jumper pinsFigure 2. Pins for the jumpers

The first problem was to figure out how those jumpers should be wired up. Their function was to select the starting addresses of the three 8k banks on the RAM board. From what I could gather from pouring through OSI literature the RAM on my accompanying 502 board (the board on the C4P that holds cassette functions and BASIC and 8k RAM) went from 0000H-1FFFH, and the BASIC started at A000H.

I'm assuming I need to configure the board so that it starts at 2000H giving me nice continuous RAM from 0000H to 7FFFH.


Here those jumpers are shown as W1, W2 and W3 on the circuit diagram (Figure 3).

Figure 3. Circuit diagram showing the jumpers

Seeking an opinion

If I had any aptitude in digital theory I could probably nut it out from the circuit diagram. As I lack any of that, I've asked for help. Hopefully asking for help is ok in Retrochallenge (it shows initiative, surely!). I put a call out to..

A lead!

After writing those emails I found something else. I discovered an article in "Micro: the 6502/6809 journal Vol 37 (June 1981)" which had a piece on adapting the OSI 527 board to a 610 Superboard. In that article was this statement:

"Jumpers W1, W2 and W3 at F9 determine the starting addresses of three independent 8k blocks of memory on 8k boundaries. No changes are made here...".

No changes. Hmm..does that mean if the 602 board has SAME memory locations for its RAM and BASIC as my 502 board then I should just wire these jumpers straight through? I checked my 602 literature on the location of RAM and BASIC and, YES, it's the same as the 502!

So..I'll wait for a day or two and see if I hear back from Frank G or the classiccmp mailing list. If I get no contrary information I'll wire it up and see what happens?

3rd July (progress post 2)

No response from Frank G., and no sign of a manual. Apparently there wasn't one, just a circuit diagram and a SAMS repair manual, both of which I have.

Getting the C4P ready

So...in preparation of RAM board testing, I dragged my C4P out of storage. Here is it, a fine looking machine.

Figure 4. The Challenger 4P. The RAM card should boost that 8k memory to 32k!

Uh oh!

Except...THE KEYBOARD APPEARS TO BE NO LONGER WORKING!!

This brings me to Tezza's 1st law of vintage computer hardware.

The probability of something failing unexpectedly and without warning is positively correlated to the age of the equipment and the urgency of use.

Actually there was a hint of a problem when I first serviced this machine. The keyboard was originally dead. I reseated some chips though and appeared to live. Seems it's reverted to it's original state.

Ok. I can't progress with the 527 RAM board until I fix this issue. This Retrochallenge will be more of a Retrochallenge than I thought.

4th July (progress post 3)

Diagnosing the keyboard issue with the help of some spare boards

Now one thing that's useful when you need to diagnosis a faulty C4P is another C4P! I don't have one BUT I have the next best thing. This...

Figure 5. NOT a pretty machine...

What is this? One could say it's a NAKED C4P. Or rather....it has the same boards as my C4P but without the clothes. There is a 502 board, a 540 (video and other I/O) board and a keyboard all of which is exactly the same as that in the C4P. The keyboard though has its own enclosure.

What's more this one works!

So...I had working replacements boards I could swap into the C4P. Hooray!

I figured the problem must be one of the following...

First I swapped the keyboard. No change.
Next I swapped the cable. No change.
Next I swapped the 540 board. That was it! System now working!!

So, now I had a fully-functioning C4P once more it was back to the 527 RAM board. Diagnosing the faulty 540 board could wait another day.

It wasn't without some tearing of flesh though (Figure 6). Geez, those multi-pin molex connectors are murder! So hard to prise apart and push back together! Do we get bonus retrochallenge points for pain and blood?

Figure 6. Molex connector induced push-pull injury

Man-up Tez, it's just a scratch!

Going for it with the 527 RAM board jumpers

As mentioned above, in the absence of any contrary information I intended to jumper the switches to the default position as shown in that grainy low res photo in the 6502/6809 journal article I mentioned above (magnified here in Figure 7)

Figure 7. The default switch connections (Incidentally, these had been scraped off on my board!)

..and so I did (Figure 8).

Figure 8. W1, W2 and W3 connected on my board.

Right, with wires soldered across the pins I inserted the board in the C4P in preparation for the big test (Figure 9)...

Figure 9. The 527 RAM board in place.

The test. Board is active but some RAM is missing

The big switch was thown...fans whirred ghostly phosphorescence appeared on the screen...pressing <Break>. <C>, then <Enter> a few times showed...

Figure 10. Definitely more RAM!

So, more RAM now than the 7423 bytes I used to have. Yay! That's progress but it's too soon to break out the champagne just yet. It's not the 32k of RAM which I would expect from an 8k + 24k set of RAM banks!?

Two possibilities. Either a RAM chip is faulty hence making every address upwards from that invisible on the startup check OR the switches are wrong and the full 3 x 8K RAM banks are not available to the system.

I really have to make sure those settings are correct before I start looking for faulty RAM. It was time to bring in the experts. I dropped a note on the OSIweb forums asking for comment. If these guys don't know, no one does.

Now I wait....

5th July (Progress post 4)

My best-guess at the switch selection was confirmed by Dave on the classiccmp.org list. A response came from there before the OSIWeb forums. Thanks Dave.

Locating and replacing errant RAM

So....it's a faulty RAM chip which blinkers the machine to full memory. It's not surprising given so many 1978 2114 RAM chips. Those ICs would have been dormant for years.

But which one was faulty? I didn't want to swap out all 48 chips to find the target. Thankfully there was an easier way. There is a SAMS servicing manual for a number of the OSI boards including the 527. The manual lists which chips are associated with which memory blocks (Figure 11)

Figure 10. Memory-IC association for part of the 527 (from the SAMS manual)

The list shows memory on the board starting at 0000H but actually there is already 8k gifted from the 502 board so we must start at 2000H. Given the amount of RAM shown on the first test I figured the RAM chip at UD3 was the reprobate.

I had a spare and in no time at all this chip was replaced (Figure 11)...

Figure 11. Part of the 527 showing the replaced RAM IC at UD3

Test number 2. YUSSS!

... and the switch thrown.

Figure 12. Full RAM. Now we are cooking with gas!

Now that's more like it! Hooray!!

The C4P is now recognising the full count of memory! The 527 board seems fully operational. Primary objective achieved!!

What now?

Plenty more to come. It's still early in Retrochallenge and there are the secondary objectives of getting cassette capability wired up and loading and saving successfully to my PC through the sound card. Once I do this, I also want to push the board with testing software just to make sure everything is AOK.

Also...I want to see if I can fix that faulty 540 board. I might do some preliminary investigations on that first. Having non-working gear annoys the hell of of me!

6th July (Progress post 5)

I had a quick look at that faulty 540 board. There is some weirdness going on but I'll set that aside for now. Now that I've got the RAM board working the focus is to get the C4P cassette-enabled so I can load and store programs.

However, before proceeding with the narrative let's have some context.

The C4P seen in Figure 4 was gifted as a residual from the defunct Wellington OSI club. I wrote a piece on it when I first checked it out. It seems to have been a disk-based C4PMF which was downgraded to a cassette-based C4P. By that I mean a 505 board with the disk controller was removed and a 502 board shoved in it's place. The transformation wasn't complete though in that no one had bothered to wire the cassette interface up to the sockets at the back! A late 1970's computer without any off-line storage capability, even if it's only cassette, is less than complete hence the task at hand.

Where is the cassette circuitry?

The first job was to figure out where these cassette lines were on the board. I found a schematic for the OSI502 on Mark's Ohio Scientific (OSI) Board Catalog which helped with this. This showed me that the cassette interface input/output lines could be found in one of the molex sockets on the board.

Figure 13. Cassette lines in the J2 molex plug

Figure 14. Showing the position of the 502 molex socket containing the cassette lines

All I needed to do was to get a molex plug, connect some wires to it and then connect those wires to the appropriate sockets at the back.

Sourcing a molex plug and wiring it up

Hmm...where to get a molex plug at short notice? Then I realised that I had some spare molex capacity in a plug I already had for the naked C4P. This plug held the video line, but only two of the six pins were needed for this. A quick snip with some cutters and I had my 4-pin molex plug!

Figure 15. Making use of excess capacity. Voila!, a 4-pin molex plug

Time to wire it up. I found four individual wires and wound them together to form a cable of sorts. Then I soldered these to the appropriate plugs. A few minutes' work and that was done. White for MIC, Orange for AUX, blue for INPUT and of course black for GROUND.

Figure 16. Molex cassette plug wired up

This neatly plugged into the molex socket on the left side of the 502 board, next to the reset lines.

Figure 17. Internal cassette cable plugged into the 502 board

Which output? CAS or AUX?

At this stage though, I faced a dilemma. There was only ONE cassette output plug on the back of the case but there were TWO outputs available, CAS and AUX? The C4P manual I have labels that single cassette output at the back as "Cassette Mic". I guess this was for complete flexibility as not all cassette recorders have a AUX input. However, I've always felt AUX was better for direct connections and the option was there. Which one should I wire up?

A quick test

I decided to go with AUX BUT I wasn't 100% confident it would work. Before wiring up the back socket therefore I wanted to test it first. To do this I wired up a temporary jack to the AUX line, screwed the C4P case back on and attached a speaker to this AUX line. I then booted into BASIC, typed out a small program and SAVEd it.

Figure 18. Start of the cassette interface test. A temporary jack connected to AUX line and plugged into an external speaker

Sure enough the shrill shriek of data been saved could be heard on the speaker. Yes!

Next time: The real thing!

Next question: Would that output save to a real cassette in a cassette recorder and could I load it in again though the INPUT line? That will be the real test. Easily tested by saving onto tape using this temporary jack, rewiring to jack to INPUT, then seeing if I could load the program back in.

Unfortunately my spare time was up. Something for another day.

7th July (Progress post 6)

Testing LOAD and SAVE

Now for the real test.

I dragged out a cassette recorder, connected it up, typed in a short listing and SAVEd the program to cassette.

Figure 19. Wired up to input a saved program

That seemed to work as I could hear the characteristic screeching over the cassette speaker. I then rewired the jack to INPUT, plugged the other end of the cable to the EAR of the cassette recorder, rewound the tape, RESET the computer then typed LOAD <RETURN>.

IT WORKED!!

Here is the process:

Figure 20. Cassette LOAD sequence on screen

Cassette LOAD and SAVE is an odd processes on the OSI. It's more like serial input/output with an echo to the screen. The LOAD command displays any random kind of noise on the tape until it strikes the program. Once it does, it loads the code into RAM as it displays it on the screen at about typing speed. You can see the program flowing in. A LIST once it's in confirms a successful load.

So YAY, the cassette interface is working. Next job is to get the machine apart again and wire up the internal cassette cables to those RCA sockets at the back.

Wiring up the RCA sockets

Figure 21 shows these sockets. The centre one is the INPUT line. You can see this has nothing on it at all. The AUX/MIC one does have a wire on it already though. I can only guess at what this wire does. It's coming from an after-market mini-board which is labeled as "Computer Consultants RF Modulator 1980". I'm assuming it is what it says it is and maybe that connection is indeed for a TV aerial? I didn't test it. The wire was coming from a place on the mini-board labeled 5 volts? It certainly wasn't carrying 5 volts. Anyway, I disconnected it as that socket is suppose to be for the cassette interface and I needed it.

Figure 21. Cassette RCA sockets prior to wiring them up. Note the RF modulator card.

Just out of interest, I thought you might like to see the other side of this RF Modulator card. You can see it also has wires going to the AUDIO, DAC and AC CONTROL RCA connectors.

Figure 22. Other side of RF Modulator board

I pondered a while on how to tackle wiring up the sockets. It was a tight space to solder in. One option was to remove them, solder the wires on, then replace them. However, this would involve desoldering the wires on the molex plug so I could thread the wires through the chassis holes when replacing the RCA plugs.

I decided the best approach was to remove the plugs, clean the contacts, add some solder on the lug, then replace them. I'd then try to work around that narrow space to solder an individual wire on each. It shouldn't be too hard if the wires are tinned and there is solder on the plug lugs. Just a touch of the soldering iron should be all that is needed.

Figure 23. RAC cassette plugs with lugs cleaned and tinned with solder

Once this was done it was a matter of screwing the plugs back in, then gently soldering the correct wire onto each one. MIC and GND were not needed so I wrapped those back on the cable and covered them with insulating tap so the bare wires wouldn't touch anything and cause problems. I also wrapped up the tip of that wire coming from the RF Modulator board.

Figure 24. RCA plugs now connected to the cassette interface

Done! I screwed to case back together, and tested the SAVE and LOAD Cassette functions once more as a final check. The programs saved and loaded without fault.

My C4P is now fully cassette-capable!

Stocktake and future plans

So far I've managed to:

  1. Fix the 527 RAM board (the primary objective)
  2. Wire up the C4P so that it can save and load to cassette (a secondary objective)

There are still a few things to do though. The 540 board in the machine is not the original board. It's a replacement I swapped in earlier in this project when the original board stopped working. This new board seems to be missing some components in particular a PAL colour daughterboard and crystal. The 540 board is suppose to produce colour but without those extra PAL-friendly components, maybe it wont? I want to check this out and if not, try to repair the original board and get it back in there.

Once I've done that, there is still the challenge of getting the C4P to save and load to the hard disk in lieu of cassette. So much more convenient.

I'd also like to explore the sound capabilities of this machine.

8th July (Progress post 7)

Question: Is the replacement 540 video board colour-capable like the original?

My C4P is now fully working. However, as mentioned above the 540 board now in the computer is a replacement one sourced from some spare parts. I wondered if this replacement board had color capability? OSI documentation does say there are two versions of this board, one colour capable, the other only black and white. Although I never tested that original board for colour, I suspect it was PAL colour enabled.

Figure 25. A PAL daughterboard in the original 540

Why I think that is shown in Figure 25 and 26. The former shows an area of the original board. There is a daughterboard with 540 OSI/PAL written on it and a large crystal at the top. Contrast this with the replacement board in Figure 26. That region is quite empty.

Figure 26. Same region on the replacement 540 video board

Only one way to tell for sure and that is to give it a try.

I hauled out a colour TV with a composite video input and connected the machine to it. It gave a reasonable image, although not as crisp as the green screen. This was expected. It had a late 70s/early 80s composite video look about it, similar to what you see with Apple II composite colour video or CGA in the IBM PC and XT.

I found a routine in the C4P manual for producing some colours and graphics. Graphics I could do (note the ships at the top of the screen) but colours? Nope. The screen remained stubbornly black and white (or rather black and pale blue).

\

Figure 27. Graphics but not colour on my C4P

Oh well, that settles it. That replacement board is monochrome.

Next step. Repair the original board

The fact that my C4P has gone from colour to monochrome in the course of this project irks me. So much so, that the next step in this Retrochallenge is to get that original board working again. I've never seen my C4P produce colour, and at the end of this project I want to have a fully maxed out, colour capable, cassette based C4P.

I must make it so!

9th July (Progress post 8)

Actually there has been no progress and unlikely to be any today. I'm not going to be able to get out to the computer shack tonight but I do have something for those who (if any!) are following this blog...

A little about the Ohio Scientific Inc. Challenger Computers

These machines aren't as well known as the Apple II's, Commodore 64s or Sinclair Spectrums so I thought I'd spend just a few minutes discussing them. It will give some context to what I'm trying to do here..

The Ohio Scientific Challengers models were sold between 1975 and 1981. From what I can read, OSI's strategy seemed to focus on a series of circuit boards. Some of these were kits and trainers but others were used to build the Challenger range, mixing and matching the boards within an enclosure to whatever market they were aiming for. These boards can be seen on this excellent page.

The best known Challenger is the 1979 Challenger 1P, which has at it's heart a Model 600 Superboard II. This is the first OSI product to offer a complete computer (including the keyboard) on a single board. In fact they claim to be the first computer to do so. Although the Apple II, TRS-80 model 1, Commodore Pet and other "consumer-type" computers of the time had keyboards in the same case, these were connected to the mainboard by a cable not integrated into it.

The OSI also sold the bare Superboard II. Naturally it was much cheaper than those computers mentioned above and allowed hobbyists with an electronics bent to explore the new world of computers providing they were happy to supply their own 5 volt power supply and case. Even made up and sold with an OSI supplied case and PSU (as the Challenger 1P), the computer was still cheaper than the competition.

A Challenger 4P (C4P) like mine was released in 1980. However, it is actually 1978 technology; earlier than the Model 600 Superboard II and C1P despite the having a higher digit than the latter. Prior to 1980 the Challenger 4P was known as the Challenger II-4P. To make up a whole computer, the cassette-based version has a minimum of three separate boards; The 502 containing the ROMS, RAM and cassette interface, the 540 containing the video circuitry (either black or white or colour depending on components present) and the 542B containing the keyboard and sound circuitry (yes, you read right. the sound circuitry was in the keyboard circuit-board!). Optionally you could also add a RAM expansion board like the 527. The latter was essential for disk drives. Disk-based models like the C4PMF had a 505 board with a disk controller instead of the 502. Apart from the board housing the keyboard, the OSI boards in the case were connected together using a Molex backplane.

OSI placed a heap of exciting interfaces on the C4P...the kinds of things which you would buy separately on a plug-in card for the Apple II. Here is an ad, showing the C4P. Note the impressive specs, interfaces and relatively low price. The ad is 1980 but appreciate the display and sound specs were available (in the Challenger II-4P) in 1978.

Figure 28. C4P advertisement probably from around 1980
(Credit: Retro Scan of the Week. Jan 8th, 2007 at http://www.vintagecomputing.com/index.php/archives/257/retro-scan-of-the-week-ohio-scientific-challenger-4p)

How were they received by the market and why weren't they more popular?

OSI machines were wonderful for hobbyists. They were cheap, used standard components, had widely spaced tracks and the circuitry was easy to get at. Technical details were available. They were great to tinker with especially if your main interest was electronics and hardware.

Unfortunately not everyone was interested in that. In the late 1970s there was a small market for hardware hobbyists but there was a growing and greater market for those that (1) were interested in the software side of computers and (2) wanted computers just to "do" stuff, like spreadsheets, word processing and games. They had no interest in what was under the hood.

OSI computers were built by engineers for engineers. They didn't have a Steve Jobs, who knew that marketing and aesthetic design was just as important as the engineering. OSI documentation is terrible. It's not that the information isn't there...it's just that it's poorly laid out and presented...almost like an afterthought. It's also very technical and assumes a fair degree of knowledge of the way digital computers work. It's rather scary for the beginner.

The sheet metal cases would have been OK in the 1975-1976 Altair days but by the late 70s/early 80s, these looked unprofessional and clunky.

I can't comment on how effective (or ineffective) their distribution network was. This may have also been a factor in low sales.

All these things combined to make software for the machines very scarce. Consider the 1978-1981 colour CII-4/C4P. It had good graphics, lower case, colour, sound...and yet hardly any software exists (at least on the Internet) which takes advantage of those capabilities. The 1978-1981 Apple II/II+ also had those things, but in contrast to the C4P, software abounds!

Should they be loved and remembered fondly?

Definitely! If your interest was in the bare metal and learning how computers work at that level, the low-cost Challenger series were hard to beat. It's just a pity there is such little software to show off the hardware, especially with the C4P.

10th July (Progress post 9)

Hidden in plain sight!

No tinkering today but instead something from the "You've gotta be kidding me!" department.

The first few days of this retrochallenge saw me trying to nut out how to set jumpers on my 527 RAM board. There didn't seem to be documentation anywhere so I had to take a best guess and confirm it with others.

Well, last night I was flicking through my copy of this...

Figure 29. First Book of the Ohio Scientific Vol. 1

...and I found, hidden in the middle...this...

Figure 30a. First two pages showing how to configure a 527 RAM board

Figure 30b. Last two pages showing how to configure a 527 RAM board

Hells bells...it was hidden in this book all this time!! And I mean hidden. Here is the index.

Figure 31. The Index. Red arrow shows where the 527 RAM board was discussed

There is absolutely NO sign that board is discussed in this book. The index just has a section that says "New Products". As it is, that part actually discusses a number of the boards although you wouldn't know it from the section title.

The docs were under my nose all the time! Grrr...However, its buried nature is a reflection of the OSI's terrible documentation. In fact, check out this scathing review of the book from Compute!, January 1981.

Enough angst. Hopefully I'll get back to the hardware tomorrow.

11th July (Progress post 10)

Fixing the colour 502 (I think!)

Recall I wanted to fix and re-install the original 540 video board, which I'd discovered in the course of this project was the only one with colour capability. The fault: For some reason that board didn't recognise the keyboard.

I set the board up with my "naked" C4P OSI (Figure 32), which I like to call my test rig. To my surprise, everything worked? Huh? How come? A few days ago, I'd isolated the problem to the board so what gives?

Figure 32. Testing the "faulty" colour 540 on the test rig

Not being able to find anything wrong, I put the board back into the main C4P. What?? It didn't work, showing the same symptoms as before. Weird.

I removed the board and put it back on the test rig. Now it seemed fine!!??

I was really puzzled. I thought I'd eliminated the main C4P keyboard and cable as a potential problem? Why does the replacement board work with them, yet not the colour one. And why does the latter work in the test rig?

I wondered if it could be a bad connection or a dry solder joint on the keyboard connection socket (Figure 33)? I'd had a dry solder joint on a socket causing bad behaviour in a Commodore PET in a past project.

Figure 33. Socket for keyboard cable on the 540 prior to clean and solder reflow underneath

Acting on this hunch I reflowed the solder on the other side of the keyboard connection socket as well as giving it a clean. I also changed the keyboard cable in the main C4P with a spare I had. I then put the colour board back in the main machine.

This time the keyboard was recognised. I played around with it for several minutes and the keyboard performed flawlessly.

Well...it seems to be going now. I'm not 100% sure I've got the root of the problem but there is a good chance it was a dry solder joint that needed to be reconnected properly. The cable orientation differed on the main C4P vs the test rig and maybe this put a different tension on the faulty connection, causing the connection to be made In the test rig but not in the main C4P?

Anyway, it seems to work now. Tomorrow I'll give it a comprehensive workout and see if I really do have colour and sound!

13th July (Progress Post 11)

Family and job commitments are making it hard to get an extended block of time on the OSI. However, this weekend I did snatch an hour or so, although it proved fruitless in the end. Read on..

CEGMON. A solution to the backspace issue

I now had the original 502 board back in the C4P but before I closed the machine up to test for colour and sound, and swap over a mono monitor for a colour one, there was one other thing I wanted to do.

The standard 502 and 600 board OSI ROM lacks the capacity for a true on-screen backspace. There is a key called "rubout" on the keyboard but this appears to do nothing. If you want to backspace you need to press <Shift-O>. This deletes the most recently typed character BUT you don't see this on the screen. Instead you see an underscore (i.e. a "_") to the right of the letter concerned! This means that character has been deleted. However, you can only see it's been deleted when you LIST the line.

How quaint. It harks back to the teletype days where input was shown on paper as typed characters. Cute it might be but it's a pain in the ass, especially when you make as many typing errors as I do.

Anyway, I noticed something strange. My test rig setup DID backspace normally when you pressed "Rubout" which was easier all round. But why did it work in the test rig but not my standard machine?

After doing some digging and further reading I discovered this was because one of the chips in the standard ROM (one called SYNMON, which also contained the monitor program) had been replaced with an EPROM called CEGMON. Not only was CEGMON an enhanced monitor but it also had the virtue of providing a REAL backspace!

Figure 34. Booting up with CEGMON on the test rig (note it also starts the boot display from the top)

Figure 35. The CEGMON EPROM

Cool! This is the solution to my backspace headaches. Why should CEGMON be wasted in my test rig when it could be making life easier in the showcase C4P?

Figure 36. The SYNMON ROM

Surely it's just a matter of removing SYNMON from the exiting 502 board and dropping CEGMON in there?! After all, it's the same size chip in the same place on the board, right?

Problem is...it didn't work. For some reason the C4P refused to boot with CEGMON. Hmmm.. I swapped the EPROM back to the test rig. It worked. Back to the C4P again. It didn't work. Ok...

It crossed my mine that maybe it wasn't a simple case of replacing the old monitor chip with this upgrade. Maybe something else was needed? Back to trawling for documents...

CEGMON: Not just a simple swap in

After more research I found what I was looking for. It seems using CEGMON is not as simple as dropping the appropriate EPROM in the SYNMON socket. Some track cutting and hardware tweaking is also required. The odd bit of re-wiring I could accept but I didn't want to start cutting tracks in my original C4P, even if it did give me a more convenient experience. I wanted to keep things as original as I could.

I decided to stick with SYNMON.

Oh well. I'll just have to get used to that <SHIFT-O>. At least I've now got that key sequence embedded in my own memory. (-:

I've now bolted the case back together again. Tomorrow will be all about testing colour and sound.

15th July (Progress Post 12)

When I first got the C4P I did carry out a basic checkout but that was with a mono screen. As it is now obvious the computer is colour capable it is time to explore that aspect of it.

Colour and graphics demo code in the user manual(s)

I found two OSI C4P user manuals on Dave's OSI website. One appeared to be an earlier edition consisting of just typed sheets. The second one, presumably a later edition, had much better layout and design. They differed a little in content also. For example the first manual appeared to have nothing on sound whereas the second manual did.

There was a short section in both manuals dealing with graphics and colour. It was very short..the bare minimum really. Colour in the 540 board (in the C4P) is controlled by a series of POKE commands. Graphics are not really true graphics. They are formed from various shapes in the character set, similar to PETSCII characters in a Commodore 8-bit machines. Some of these shapes are accessible through the keyboard and can be PRINTed on the screen. All can be set at a location on the screen using a POKE command.

Example program 1. First try

There were two example programs. I typed in the longer one, which was suppose to fill the screen with columns of different coloured ships, and typed RUN.

Well there was colour but only a single row of ships at the top....Hmm..

Figure 37. Coloured ships code FAIL
(P.S. ignore the code on the screen...this photo was obtained by amending line 60 in the correct code listed on the screen to the
original wrong code and then running the program (see below). I forgot to take a photo of that FAIL on the first try!)

Manual mistakes

I'd typed the code in from the second, more presentable manual (Figure 38). The code I'd typed in certainly matched that. But wait...a check on the same section on the first manual showed a slightly different code at line 60 (Figure 39)!

Figure 38. Code originally used i.e. the code in the later manual

Note the line in pink. Compare that line with line 60 from the first manual below. It's different, right?

Figure 39. Code in the early manual

Example program 1. Second try

Maybe the code in the later manual was in error? I changed line 60 to what was written in the earlier manual and I got this:

Figure 40. My coloured ships!

That's more like it. The colour seemed to be working just fine.

Example program 2. First try

There were two sample programs in the manual so I decided to type the second one in also. This was suppose to colour the screen red and put an X in a blue square in the centre of the screen. What I got as this:

Figure 41. Err...not quite lined up

OK, that wasn't suppose to happen. I wondered if the code was wrong in the later manual again. A check of the first manual showed the same code though. Hmmm...

MORE manual mistakes!

But wait...after reading about how the colours and graphics were mapped I discovered the code was wrong in BOTH manuals this time! Figure 42 shows what was there, and what should be there.

Figure 42. Another misprint, this time in both manuals

Not only was the POKE address wrong but a keyword "TO" had been used for a variable!!?? I spotted this one before I even typed the code in.

Example program 2. Second try

Now with the code corrected, I saw this:

Figure 43. The expected behaviour from the test code

Now that's what I'm taking about!

Reflections

So, colour and graphics are working just fine. It was quite a thrill to see that. The C4P is a little like the Apple II. There are no dedicated proprietary chips as there are in the common home computers of the early '80s. Colour is produced by clever tricks with the circuitry.

What was astonishing were the mistakes in the manual! In the second, more professionally produced manual, BOTH of the two demo programs present (which are, in fact the only demo programs in this section) were in error! How frustrating that would have been for the novice user. I said earlier that documentation was a real weak point with these OSI machines and the more OSI docs I get to use the stronger that conviction becomes!

Still, it's great to see a machine of this vintage (1978 really) producing those colours and graphics.

In the next blog entry, I'll write about the sound test.

16th July (Progress Post 13)

The OSI produces tones (but not as musically as it should)

Just a quick update as I've only got a few minutes to throw something down.

The OSI C4P sound works. I wired up the SOUND OUT port up to the audio in of my monitor (Fig. 44)...

Figure 44. Video and audio inputs to my colour composite monitor/TV

...and ran this little program from the C4P manual (Figure 45).

Figure 45 Twinkle, Twinkle

Clear audible tones hitting those notes were heard. However it wasn't quite like the score. Rather than crochets with a semitone at the end, the separate crochets pairs were heard as a semitone. There was no break between them.

I'm pretty sure this is the listed program rather than any hardware deficiency. I haven't had time to analyse it but I suspect (like the other listings) it's not quite right.

As with the video demos I'll try to repair this program too.

17th July (Progress Post 14)

Ok, I looked at that code again. I got some helpful suggestions from other Retrochallengers via Twitter too.

The program was missing a POKE to give a split second of silence between the notes thereby separating them. I added extra code within the T loop at Line 85. That did it. I also switched off the sound with another POKE at the end of the sequence otherwise the C4P continued to produce one long continuous tone (Fig 46)!

Figure 46. Correct code for sound demo

Take a listen to what the code produces (Don't get too excited though).

So, another faulty listing in the OSI documentation. Was it deliberate just so people would troubleshoot and learn BASIC that way? More likely there simply wasn't enough time or effort applied to the docs. It may have simply been a lack of money to do everything well. The more I get into OSI gear the more I can see that the hardware was king. As I've said before, computers built by engineers for engineers.

Next up. Saving and loading programs from the PC's hard disk through the sound card.

19th July (Progress post 15)

Ok, time to take stock. With this OSI C4P so far I had:

Loading and saving cassette files as WAVs

I 'd already successfully LOADed and SAVEed to and from a real cassette in a real cassette recorder. However, I like to keep all the cassette-based files for my vintage computers in just one place and that place is the hard drive of my XP machine. I've got many programs stored there as WAV files, which I can load into retro/vintage computers. These include my Sinclair Spectrum, Spectravideo 318 and 728, Aquarius, Colour Genie and a few others. For saving and loading the programs on the PC I use Audacity. Input and output go through the sound card.

The OSI C4P uses a protocol called the Kansas City Standard (aka the "BYTE standard"). This protocol was developed in 1975 and was common amongst S100 computers, the SOL-20, the Acorn Atom and others. It uses a fairly pedestrian transfer rate of 300 bits per second. A "1" bit is represented as 4 cycles of 1200Hz and a "0" bit is 8 cycles of 2400Hz. This same protocol is used by my Challenger 1P. I'd manage to load and save programs from that machine on my hard drive as WAV files so I wasn't anticipating any problems.

The only was to find out if WAV saving and loading would be successful with the C4P was to try it...

Figure 47. Wired: For sound (right top), for video (left top) and for WAV input (middle left)

Results

Both SAVE and LOAD work like a charm. Indeed the system seems quite robust, tolerating a wider volume variation than many of my other machines.

Figure 48 Loading in an OSI program through Audacity

So, loading and saving those test programs as WAV files on the PC hard drive was quite straightforward. I could now put the cassette recorder away.

The next task is to see what other software was "out there" on the Internet for OSI C4P.

20th July (Progress post 16)

Software libraries

Loading and saving files to and from the PC through the soundcard as WAV files was no problem. Was there any Internet-sourced software about though?

As it turns out, there was and I didn't need to look far. Some time ago, I'd built up an Internet-sourced software library for my Challenger 1P. In the course of this project I'd collected quite a few programs. However, some I just filed away because they didn't work on my 22 characters/line C1P. They required at least 32 CPL or more, so were for either modified C1Ps, C4Ps (or higher).

I tried some of these programs out and they worked! Not surprising really, as the main incompatibility between the cassette-based C4P and the C1P was the screen resolution, sound and colour. The BASIC is essentially the same.

Here is one I found in the stash...

Figure 49. Invaders for the C4P

It may not look much but it's a fun game. The idea is to maneuver a ship, represented by an X, around the close stars (the blocks) and ram any enemy ships as represented by "O"s. Hitting a star means instant death and the "O"s increase randomly and quickly. Figure 49 shows the game when it starts off, before the enemy ships start multiplying.

Figure 50. Invaders credits

The game is called Invaders but it's not the classic shoot-em-up. Just to prove I'd haven't misnamed it, I give you the first 3 lines of the program listing (Fig 50).

The file format for Internet-source Challenger programs

Internet-sourced programs for the Challenger series tend to come in the simplist of formats. They are just text files. The OSI emulators use this format to load and save BASIC programs. This means they can easily be tweaked and amended.

Text files to WAV

To convert one of these program listings to a WAV file to use on a Challenger is easy. This is done using a very handy freeware command-line program called KCS. The KCS stands for Kansas City Standard, which is the audio format used to represent binary.

One of the programs I used KCS on was one sent to me by Philip Lord (Nama). This was a RAM tester. My RAM board seemed to be working just fine but I wanted to test every one of those 48 chips.

Figure 51. KCS after it had "done its thing"

KCS converted the file to audio just fine (Fig 51) although I had to tweak the BASIC code so the RAM starting address was right for my configuration once loaded (Fig 52). It was then just a case of starting it, walking away and letting the software do its thing.

Figure 52. Here it is counting up the HEX. No worries. All RAM was fine.

All objectives achieved. What now?

The C4P has had its RAM expansion repaired and tested, cassette I/O has been wired up and tested, a keyboard connectivity issue has been fixed, colour and sound has been tested and some software collected. However Retrochallenge still has a way to go; there is certainly time for something else.

Figure 53. The C4P with colour monitor and cassette save/load wired to the PC

Software demo

Perhaps have a go at software? I haven't found any programs that show off the C4Ps colour, graphics and sound. It will be fun to write something. A demo of sorts. It will be a challenge. I haven't undertaken any programming to speak of since the late 1980s.

Suffice to say it will be in BASIC, not assembly language! (-:

Time to get creative.

22nd July (Progress post 17)

The software demo has been coming along well. Here's the form it will take and how I'm developing it:

Form of the demo

I wanted this demo to tell the viewer something about the C4P's capabilities but not in the usual sense where a program shows off just the colour, graphics and sound. I wanted to get the C4P to narrated its own features to the viewer so that those watching get a sense of the whole specifications, not just the multimedia bits. I also wanted to convey the sense that this is technology from 1978-1981. To do this, I wanted the machine to have its own personality...that of a somewhat grumpy and ignored old man, well past the prime of life but still feeling that there was some relevance there somewhere. (P.S. any relation to anyone living or dead is completely coincidental!). That should make the demo more informative and, hopefully, entertaining in a cheesy late '70/early '80s kinda way.

I decided to break the demo into four parts:

  1. A narration where the C4P simply discussed (in text) the basic specs including the features of its 8K BASIC.
  2. A short graphical kind of hunt-the-wumpus game which shows off some of the colour and graphics. It would be a demo where the computer would hunt for the wumpus itself.
  3. A little piece showing the 32 character mode.
  4. A final segment listing the built-in interfaces.

Programing challenges

There are a number of challenges.

  1. The BASIC is very basic (excuse the pun) and anything smelling of colour, graphics or exact screen placements has to be achieved by PEEKS and POKES.
  2. The OSI BASIC editor is hard to use in that there isn't one. A mistake in a line means it has to be retyped. There is a backspace "of sorts" in that a key combo will delete a character to the left of the cursor but you don't see this on the screen. You just see a "_" to the RIGHT of the cursor.
  3. The programmer (yours truly) has the status of "rank amateur" and this doesn't bode well given (1) and (2)!

The development platform. WinOSI

There is a 2008 emulator available for the C4P called WinOSI. It's not the whole package but it is easier to develop the code on this than the real machine. Having an emulator is great but there are limitations mainly:

Given the last two points, I found it was best to write the code in self-contained sections (so it wasn't too long) in NOTEPAD and save it and load it into the emulator each time I edited it (The emulator won't allow a simple paste). It's a hassle, but not as much hassle as retyping lines on an unfamiliar keyboard layout every time I wanted to add or amend something!

Figure 54. WinOSI and my code editor - Windows Notepad

Unfortunately I can't finish the program entirely in the emulator. I'll need to get it into the real C4P to add the sound. That will be the final task.

Watch this space for updates on the various code sections as I develop/debug them...

(P.S. I changed the title of this blog as the RAM board turned out to just be one of many OSI C4P activities)

24th July (Progress post 18)

Progress has been good and the program is well on the way to completion. I'm at the stage where I just need a session to tidy up a few things...then I'll move the code to the real C4P to add the sound routines.

I thought I'd mention a few characteristics of the demo, and the programming design I used to implement various things. This will be spread over a few days as blog time is limited at the moment.

Code for the narration

I wanted the computer to "talk" to the viewer. Not with audio, but with slow scrolling text on the screen. At the speed of a typist so that it had kind of an organic feel. The kind of streamed text you might have seen when communicating with one of those computers in pre-1980s films (or an BBS back in the 300 baud days). Teletype even!

I also wanted the computer to pause between paragraphs. As if it was catching it's breath, or thinking.

Lastly, I knew I would probably alter the text a lot as I refined the program during development. I thought it best then that the text be read in from DATA statements at the end of the program. This way I wouldn't need to squeeze new text between pre-existing line numbers. This would have been the case had I embedded the text in sequence in the code using a PRINT statement.

So. Here is the subroutine that prints most of the text on the screen.

1999 REM SCROLLING WORDS ACROSS THE SCREEN
2000 READ WRD$
2010 LL=LEN(WRD$)
2020 FOR I = 1 TO LL
2030 IF MID$(WRD$,I,1) ="#" THEN GOSUB2100:PRINT:PRINT:RETURN
2040 PRINT MID$(WRD$,I,1);
2050 REM FOR J=1 TO 20:NEXT J
2060 NEXT I
2070 PRINT
2080 RETURN
2099 REM DELAY SUBROUTINE
2100 REM FOR J=1 TO (DELAY/2):NEXT J:
2110 RETURN

Loops in the body of the code (not shown) corresponding to main segments of the demo jump to this subroutine. A data statement is read. Each character is then displayed on the screen using the MID$ function with a small delay loop so they don't appear too fast.

If a line in the DATA statement is the final one in a paragraph it has a "#" at the end. Line 2030 checks for this and, if found, jumps to another subroutine (2100) which adds a delay (as if the computer is gathering its thoughts). The value for DELAY is specified at the beginning of the program so I can easily change it. The sequence then jumps back to line 2030 where the code prints two line feeds/carriage returns to make a paragraph break, then jumps back to the main program. The loop which called the subroutine increments, and (assuming it isn't the end of the loop) calls the routine at 2000 again to display the next sentence.

This works well.

Clearing the screen

The OSI 8k BASIC doesn't have a clear screen command like CLS or a special ASCII character that also does the job when PRINTed, like the Commodore 64. Interestingly the newer CEGMON ROM (see progress post 11) does provide a "screen clearing" ASCII code but it is not in the original SYNMON, which I've got.

Consequently, clearing the screen takes the crude (and slow) approach of either PRINTING a number of blank lines OR (where colour is being switched), POKING a "space" (ASCII 32) character (of the appropriate colour) into every one of the screen locations.

Machine code routines can give a fast and more elegant screen clear but unfortunately I don't have the time to get my head around hybrid BASIC/machine code programs and the USR(I) command in the time available.

Placing text exactly where you want it

This has been one of the biggest headaches. There is no PRINT@ or LOCATE command which can place text just where you want it. The PRINT statement will always start it at the bottom of the screen, and scroll whatever text was there upwards.

To get text where you want it you need to POKE an ASCII value representing the character into a screen location.

This subroutine helps. D$ contains the line of text you want to display...

2999 REM PRINT AT SUBROUTINE
3000 FOR Y=1 TO LEN(D$)-1:POKE D+Y,ASC(MID$(D$,Y,1)):NEXT:RETURN

I can't claim credit for that one. I found it in an OSI book.

Watch this space for further elaboration (hopefully tomorrow) on tricks I used to get this demo working especially with colour, graphics, a wumpus and the Starship Enterprise!

25th July (Progress post 19)

Managing colour and graphics is one of the hardest things to do on OSI machines. Simply because the 8K BASIC found on most is just not up to the job. Think Commodore 64. Everything has to be done with PEEKS and POKES.

How the Challenger 4P handles graphics

It's the same way a Commodore PET does. Essentially the graphics are part of the character set, potentially giving 256 symbols. Quite a few of them are letters (upper and lower case) and the common symbols on the keyboard but this leaves a lot of symbols over. Here is the full character set:

Figure 55. The full character set

Notice the tanks and planes there. Also shapes which when joined in pairs make up things like boats, and the Starship Enterprise going in two directions (9,10,11 and 12). Clearly SOMEONE had games in mind when the Challengers were designed!

Each symbol is a set of 8 dots by 8 dots (Fig 56). By joining some of the lines, squiggles and circles up you can get larger shapes of fine resolution.

Figure 56. Screen matrix in the C4P

The PRINT statement is useless for placing these characters though. They have to be POKEd into position on a grid as shown above. The grids differ depending if the machine is in 32 character mode or its default 64 character mode.

64/32 Character Mode

This 64 or 32 character screen mode is set with a value POKEd at memory location 56832. This determines if the screen is 32 or 64 characters wide, B/W or colour, and whether sound is active or not. Changing screen modes does not automatically clear the screen of what may have been put there before.

Colour

Here is a complication. If you want colour (assuming colour is active) it's a matter of telling the computer the colour status of whatever character you are trying to put there. You do this by POKing a value in an address which is exactly 4096 bytes more than the address value of where you've POKed the character. This will colourise that square with a colour. But how will you then see the shape and/or letter (I hear you ask)? Any of the dots that are filled in that 8 x 8 character matrix will be the same colour but brighter, so they will be seen against the background.

There is no way to globally "paint" or "fill" an area of the screen with colour. It has to be done on a character by character basis using two address POKES, one the ASCII code for the character (32 if it is a blank square) and the another (4096 bytes further up) with one of 13 colour codes. Whew!

Building a cage for the Wumpus hunt

For example....Part of the demo has a wumpus house initially invisible in a fenced off area of the screen. The first thing I had to do was to colour the whole screen blue (character by character), then build up a border using line and corner characters. Here is the appropriate code..


314 SC=8:REM BLUE SCREEN COLOUR
316 CC=2:REM RED CAGE COLOUR
317 D$="Drawing a Wumpus cage..."
318 D=55103: GOSUB 3000
320 POKE TL,204:POKE TL+4096,CC
322 FOR I = TL+64 TO LL-64 STEP 64
324 POKE I,140:POKE I+4096,CC
326 NEXT I
328 POKE LL,203: POKE LL+4096,CC
330 FOR I = TL+1 TO TR-1
332 POKE I,131: POKE I+4096,CC
334 NEXT I
336 POKE TR,205:POKE I+4096,CC
338 FOR I = TR+64 TO LR-64 STEP 64
340 POKE I,139:POKE I+4096,CC
342 NEXT I
344 POKE LR,206: POKE LR+4096,CC
346 FOR I = LL+1 TO LR-1
348 POKE I,132:POKE I+4096,CC
350 NEXT I
.........
2999 REM PRINT AT SUBROUTINE
3000 FOR Y=1 TO LEN(D$)-1:POKE D+Y,ASC(MID$(D$,Y,1)):NEXT:RETURN

All that whereas more advanced BASICs would just use a couple of commands. Those BASICS are for sissies though (-:

Figure 57. The start of the Wumpus section

Figure 57 shows the colourised screen and wumpus cage border drawn by this code. It doesn't cover the words displayed or the placement and display of my "wumpus" hunter (a tank). The latter sniffs out the wumpus house, which is hidden in the box somewhere.

More on how I hid the wumpus, and how I gave the wumpus hunter a sense of smell in the next blog entry.

26th July (Progress post 20)

My version of hunt the wumpus

This part of the demo works as follows...

A wumpus cage is drawn on the screen and the wumpus's house is hidden at a random point somewhere within that cage. The wumpus hunter (as represented by a small tank) appears in the centre of the cage and has to "sniff" the wumpus out. As the wumpus hunter sniffs around it will gradually get closer to the wumpus house until it reaches it. The wumpus house will then become visible. The demo can then be replayed (and the Wumpus house it placed in a different random spot), or the viewer can continue on.

I've described how the cage was built above. Here is how the rest of the game works...

The wumpus hunter and wumpus house.

The wumpus hunter uses the "tank" graphic character. As I wanted my wumpus hunter to point in the direction it was moving, I used all the ASCII characters from 248 to 255

Figure 58. ASCII characters for the wumpus hunter and the wumpus house

All these characters require POKING into the positions they are suppose to be in.

Hiding the wumpus

After drawing the cage, the first task is to hide the wumpus somewhere. It has to be within the boundaries of the cage. A random number (WP) representing a screen location is generated somewhere between the top of the cage and the bottom. However this number may be beyond the sides of the cage, so a check is made of every square in the box to see if the number is within those boundaries. If not, a new random number is generated and another check is made.

This code probably shows how deficient my maths is. I'm sure there is a more efficient way to do this but it works.

306 TL=53322 'These are the memory addresses which define the corners of the cage
308 TR=53365
310 LL=54922
312 LR=54965
........
379 REM CALCULATE A RANDOM PLACE FOR THE WUMPUS TO HIDE
380 WP=INT((LR-TL)*RND(1)+TL) ' Gives a random address between the top of the cage and bottom
398 REM MAKE SURE THE WUMPUS IS WITHIN THE BOX '
399 REM cHECK EVERY CO-ORD OTHERWISE TRY AGAIN
400 IF WP=TL OR WP=TR OR WP=LL OR WP=LR THEN GOTO 380
420 FOR I = TL+2 TO TR-2 'Wumpus has to be in from the boundary not on it.
440 FOR J = 1 TO ((LL-TL)-64) STEP 64
460 IF WP=I+J GOTO 500: REM FOUND SO EXIT LOOP

Seeking and finding the wumpus

As soon as the wumpus hunter is visible it starts to seek the wumpus. To do this I've got the program to choose one of 8 randomly selected positions next to the wumpus hunter. These correspond to a 45 degree angle segment. I've then associated the appropriate ASCII "tank" character pointing towards this position with a variable, so the wumpus hunter will appear to be pointing to that adjacent position if it decides to move there. This means the tank is always pointing forward.

Before moving however, the program checks if the selected adjacent position is actually closer to the wumpus or further away. If it is further away, it does not move there. Instead it loops back, gets another random adjacent position, and checks again. If it is closer, it moves to that space. A new random adjacent position is generated and the process starts over again.

Here is the code...

638 REM START OF TANK MOVEMENT
639 REM CALCULATE RANDOM DIRECTION TO MOVE
640 VL=INT((8-1)*RND(1)+1)
643 REM POSITION OFFSET AND TANK SHAPE
644 IF VL=1 THEN L=1:TK=250
648 IF VL=2 THEN L=65:TK=251
652 IF VL=3 THEN L=64:TK=252
656 IF VL=4 THEN L=63:TK=253
660 IF VL=5 THEN L=-1:TK=254
664 IF VL=6 THEN L=-63:TK=249
668 IF VL=7 THEN L=-64:TK=248
672 IF VL=8 THEN L=-65:TK=255
699 REM CALCULATE THE NEW POSITION
700 PS=START+L7
719 REM FORCE THE TANK TO MOVE TOWARDS THE WUMPUS
720 OC=ABS(WP-START):NC=ABS(WP-PS)
750 IF NC > OC THEN GOTO 640 : REM TRY ANOTHER DIRECTION
779 REM CHECK IF THE NEW POSITION IS THE SAME AS THE WUMPUS
780 IF PS=WP THEN POKE WP,14:GOTO 900:REM FOUND WUMPUS
799 REM IF NOT CARRY ON AND PLACE THE TANK AT NEW POSITION
800 POKE PS,TK
819 REM PUT A SPACE WHERE THE TANK WAS
820 POKE START,32
840 START=PS : REM NEW POSITION BECOMES START
860 GOTO 640 : REM BACK TO GET A NEW POSITION
899 REM WUMPUS FOUND! PRINT MESSAGE OVERWRITING EXISTING TEXT
900 D$="I found the wumpus! <L-Shift>=Again, <R-Shift>=Continue "
910 D=55103: GOSUB 3000
...
.........
2999 REM PRINT AT SUBROUTINE
3000 FOR Y=1 TO LEN(D$)-1:POKE D+Y,ASC(MID$(D$,Y,1)):NEXT:RETURN

This animated GIF shows two random wumpus hunt in the OSI emulator. There is a flash of Windows 7 between the hunts as I had to switch between the animated GIF builder and the emulator to press the LEFT SHIFT button to restart.

Figure 59. Two wumpus hunts (on a loop)

The next blog entry will discuss my success (or not) with a teletype sound effect for when lines are being typed. For this I'll need to convert the code to a WAV and load it into the C4P. Hope it works?!

27th July (Progress post 21)

Loading the demo into the real machine

Now the moment of truth. I needed to load the demo into the real Challenger 4P to work out what sound I was going to include. This was going to be a test of the KCS conversion utility described in progress post 16 as well as the "WAV to Challenger loading via PC sound card in lieu of a cassette" procedure. I estimate the program is about 10k in length which is a fairly substantial for a Challenger. I now had the RAM to cope with it though.

The good new is both procedures were totally successful. The program was converted from the text file to WAV, and loaded into the Challenger without issues.

Well, actually there was initially an issue. The Challenger missed the first character or so off the occasional line using long WAVs created by KCS's default mode. You could see this happening during the load as the Challenger lists these lines on the screen as they come in. These first characters were line numbers so it was pretty important that they were right. However, the problem was fixed using a switch on KCS's command line interface that told it to insert a couple of blank lines after each end of line. The Challenger ignores these blank lines and it seemed to help it to "keep up" with Audacity's WAV output.

Sound effects

The Challenger can produce sounds two ways. One way is to use its tone generator. This involves POKEing a number from 1-255 onto a location to produce an audio tone of so many Hertz. The second is to use the digital AC converter to produce a sawtooth audio wave. The latter gave far more sophisticated effects but could only be accessed through machine code. Given Retrochallenge only had a few days to run (plus I knew ziltch about 6502 assembly language) I opted for the simpler method of POKEing tones.

Figure 60. Keyboard related to the Hertz values able to be used in the tone generator.
From the C4P manual's appendices

Typing tone

I wanted the OSI text to sound a little like it was being produced on a teletype. You might remember episodes of the original Star Trek where computers, even if they were speaking, had this typing/printing sound accompanying the output? My feeling was this would give the demo a little more character and fit right into the old 60/70's theme of how computers were regarded back then.

It took me a bit of testing and I never really found tones I was entirely happy with. I did find a tone combination which, although it didn't sound like a teletype, was acceptable as a typing tone. Lines 2045 to 2060 in the code below shows its implementation...

12 LET SD = 57089 : REM FOR SOUND POKE
....................
1999 REM SCROLLING WORDS ACROSS THE SCREEN
2000 READ WRD$
2010 LL=LEN(WRD$)
2020 FOR I = 1 TO LL
2030 IF MID$(WRD$,I,1) ="#" THEN GOSUB2100:PRINT:PRINT:RETURN
2040 PRINT MID$(WRD$,I,1);
2045 POKE SD,160
2050 FOR J=1 TO 15:NEXT J
2055 POKE SD,20
2057 FOR J=1 TO 5:NEXT J
2060 NEXT I
2070 PRINT
2080 RETURN

One important thing was to make sure I turned the tone off once the subroutine was exited!

"Jaws" music for the Wumpus hunt

thought it would be quite cool to have a sinister jaws-type tone playing during the wumpus hunt, you know....the "daa-duh, daa-duh, daa-duh..." sound. I spent quite bit of time experimenting to find a couple of tones and durations down in the lower frequencies which might sound menacing. In the end though, I wasn't happy with anything I could produce. I did find a couple of tones suitable and with small gaps between them which produced a kind of "daa duh". Once I added it to the wumpus code though it just sounded lame. I decided the reason was because it be menacing it really needed to ACCELERATE in intensity as the hunt went on, just as it does it Jaws. Thinking about what I'd need to do in the Wumpus code to achieve this I decided it would be just a bridge too far (actually, several bridges too far!) given the short time-frame. The wumpus hunt remains then, a silent stalk.

Plans for the next few days

Next up, it's tweaking the demo text a little to give it some more personality. I'd like interested parties to see this in action so I've give some thoughts as to how I might achieve this. A screen grab in the emulator would do it, but no one would hear the sound. Maybe a Youtube video summarsing my whole retrochallenge effort and showing the demo on that video might be the way to go.

29th July (Progress post 22)

The demo is now complete. I'm happy with it now.

The demo program in the emulator (sans sound)

Here is the demo program movie screen-grabbed in the OSI emulator. It's without the sound as the OSI emulator doesn't support that. Also, it's an MP4 and you can only see it below in modern browsers (but not Opera). My apologies in advance if that's what you have. However, all is not lost as you can also download the movie and view it on your own platforms.

This will tell you something about the C4P as well as showing off a little of its colour and graphics features (not that there is a lot to show off!).

Figure 61. The demo program in the emulator (minus sound)

Note the lower-case without descenders (-:

There is a mistake in this recording of the demo in that the C4P disk board mentioned at the end should be 505 not 545. I've since corrected that.

YouTube video planned

I thought I'd make a YouTube video of the demo as a final hurrah for this project as the "typing" sound can then be heard and it proves the demo does run on a real OSI C4P. I took some raw footage tonight and will put something together in the next couple of days.

30th July (progress post 23)

Just a quick update. A YouTube movie on the software demo is in preparation (Figure 62).

Figure 62. Youtube movie in preparation in Microsoft MovieMaker

A summary post, including a links to the Youtube movie and the demo program listing will be available tomorrow.

31st July (Finish!)

Youtube demo video

The OSI Challenger 4P is now strutting its stuff on YouTube. Enjoy!

Figure 63. The software demo on a real OSI Challenger 4P

The source code for the demo is here. It is about 10k but I'm sure it could squeeze into 8k if the spaces and REM statements were removed. REM statements make a program so much easier to understand when you come back to it. Having RAM available, I used them frequently!

Final words

So ends my Retrochallenge for summer 2014 (although it's actually winter "down under"). It's been quite an adventure. I know far more about my Challenger 4P now than when I started! In the month I've managed to:

I'm sure these things wouldn't have happened without the event. It certainly forces focus. One of the highlights for me was writing the demo. Although it is short and simple, it was great to put the hardware down for a while and try my hand at coding again after all these years.

One last thing. By sheer coincidence I've just been sent a 505 Disk Board and disks by Challenger guru Philip Lord (Nama). As this C4P used to be a disk unit I already have the disk drive for it. All I need to do now is to make a cable, add a chip or two and configure what needs to be configured. Something for the next Retrochallenge maybe (-:

Tez

 
comments powered by Disqus