I haven't yet had the opportunity to try the latest firmware, but I'm on my way. At least I have set up my 610 as a standalone workstation:

http://www.geting.se/viewimage/image/287778-cbm610-corvus-setup.jpg

The Philips monochrome monitor has the option to toggle between green-on-black or black-on-green. The camera with its flash doesn't do the monitor justice, but I prefer black-on-green.

I suppose I might reconfigure my uIEC/SD to device #10 as the Corvus currently is #8 and the 2031 is #9. But more on that later...

I agree with Steve. I would have tested the most recent version a week ago if it wasn't for lack of time.

By the way, as you have seen from earlier pictures I hacked my uIEC/SD right away to fit a female IEC connector. Actually that connector came loose on the side with my C2N232I that I once bought from Marko/Nicolas. I brought the whole uIEC/SD/IEC adapter to Germany in August 2009 and the first thing Nicolas said was that he recognized the female IEC connector that he once sourced for the C2N232I. Apparently they were a bit difficult to find for a good price.

Hopefully I'll get around to test this one in the weekend or over the Christmas holidays.. well, one can always hope.

Now that Michau is working on releasing a handy, cartridge version of Uz' old IEC routines, perhaps someone should take on another hobby project and develop the CBM2-Command port after all...

Hm. I wonder if the good old software suite WAV-PRG and AudioTAP supports PET? Since the timing is inbetween VIC-20 and C64, they probably would work. In that case you could take a PRG file and convert to WAV, connect a regular tape recorder to the speaker output of your sound card and record it onto a fresh tape.

Otherwise there are a couple of different solutions involving various cables etc, depending on how much you want to work to get the desired result.

For what it's worth, SVT in this case appears to be an abbreviation of Svenska Tecken, i.e. Swedish characters. I've seen in on many of the PETs, an EPROM with that hand-written label.

Did you get it from Germany? I am not familiar to what extent the Commodore machines were localized in Germany, but the mention of DIN makes me think of Germany. In that case it suggests the Kernal ROM would have been adjusted to fit German keyboard mapping and the faulty Character EPROM would be one that gives you ÃœÃ,,Ö. All the B500, 610, 710 and 720 machines I have come across and sold have been localized to Swedish conditions with EPROMs, usually with adaptors to fit a 2764 into a 2364 slot. Then again, I am aware that Sweden held a special position in the world when it came to localized Commodore computers, much higher degree than any other non-English speaking country in the world. Virtually all machines from PET 2001N to Amiga 4000 were available in localized versions.

Great work! I should burn myself a cartridge and test it a little.

Oh yes, that is ibay_1000. I believe he or a friend of him inherited a basement full of Commodore stuff a few years ago. He has been selling a lot of boxed SFD-1001's, CBM-II parts, VIC-20 memory expansions and pretty much anything you could imagine, apart from the ultra-rare prototype items of course. It seems his supply was even better than mine was.

Hm. I gotta check what the 8296 keyboard looks like. I don't have any separate keyboards complete in casing, but I might have a 8000 series keyboard mechanism which you can replace (solder) the internal connector with a DB25. It won't look pretty but it would function.

Not sure about the power supply. I used to have one, and with a bit of luck one of my friends has a broken 8296 which he gladly lets go. I will look around and reply by PM.

I'm bumping this old topic to mention my inventory has been updated. What remains are the following:

3x PET to IEEE cables (+/- one cable, need to check my personal needs)
5x IEEE to IEEE cables (ditto)

Pricing depends on current exchange rate, expect somewhere around US$ 25-30 including worldwide postage for a cable.

I also have a few other spare parts I will give away for postage costs:

* Two empty cases from 3040 and 8050 floppy drives. Neither even has a power supply. Those probably are far too big and bulky to ship around, given they don't contain anything collectable. Might be nice to retrofit a modern PC inside?

* A handful of big folders with PET schematics etc. Several folders contain the same docs, and as far as I've found, most or all of the schematics already are scanned on Zimmers. However for anyone repairman who likes to work with papers, one of those folders might be nice. They are pretty heavy though so expect a big shipping quote.

I will try to update this list as I find more items, or anything is sold or donated. All responses by PM or email please.

Update 2010-12-12: The following items have been donated for the cost of shipping.

* Tested broken 3032 motherboard, displays only garbage even with known good ROMs + set of 65xx chips. Currently the board completely lacks ROMs and 65xx chips.

* Probably broken 4000/8000 motherboard, some 65xx chips soldered and the other missing

* Probably broken motherboard from a 3040 floppy drive, DOS 1. Lacks 6502 and 6522 but has other chips intact

* Two floppy drive mechs from 8250LP, untested as I prefer not to risk killing my working 8250LP drive (yes, I swapped around drives and controller boards before and killed a few drives due to a bad controller)

* A few PET 3000 and 8000 keyboards, may have keys missing and in worn condition

Make sure you select a PET with the piezo element. Otherwise you won't get any sound at all without hacking it. I believe the cut-off is between old style 2001N/3000/4000 boards and new style universal 4000/8000 boards, of which the latter also may exist in different editions. For example my last, remaining 4032 doesn't chirp on power on but works otherwise. I understand with the help of internal or external modifications, even those slightly older models can be made to produce sound.

Cool, I had almost given up on autostarting CBM-II cartridges...

I agree, it looks like the most number of CBM-II items are found in Germany. Personally I'm out of items.

Another option would be trying to use something like Jim Brain's keyboard adapter C=Key but it requires to be reprogrammed to match the CBM-II keyboard layout. If someone can open up a keyboard and follow the wiring, it might be possible to at least recreate the matrix for manual simulation of the signals.

The sad part is that I began to rescue Commodore stuff in December 2005. A few months earlier, the former reseller had begun to clear out garbage. He started with old matrix printers and external keyboards, both 8032-SK and CBM-II style. I managed to find a few, but according to him a number of those keyboards ended up at the dump in the fall of 2005.

Actually the B500 has been traded to a dear collector, so it is no longer my problem. 

As for tape routines, I'm not sure if it is worth the trouble. While accessing a relatively cheap IEC style floppy drive, even if it is slow and inflexible is a good addition, I wonder how many CBM-II users today would benefit from being able to use a Datasette. Perhaps for "emergency" transfer options.

Great improvement, looking forward for the results!

I believe I own a copy of that, ROM and manual. I didn't yet investigate it so I can't say for sure it is the exact same software but I recognize the layout of the manual. Actually I have a couple of expansions that I will upload to Zimmers any day now...

Payton, would you or someone else consider looking into making a CBM2-Command as well? Those machines run in 80 columns and have at least 128K RAM, although due to memory mapping issues you might find it a squeeze to switch banks back and forth if you need Kernel calls.

Does anyone have access to CMAR from Cimarron Corporation?

A friend of mine came across this package for the PET/CBM 8000 series. It consists of manual, a protection ROM and a floppy disk. According to the manual there should exist floppy versions for 4040, 8050 and 8060/8061 (i.e. 8" floppy drives).

Since he doesn't own a PET or enough equipment, he lend me the floppy disk while another friend dumped the protection ROM. Sorry to say, I am so far unable to read the contents of the floppy disk. First I tried it in my 8250LP, but it wouldn't detect anything at all. Then I tried a 4040 with DOS v1, which is flaky on its own. Still I got no coherent readings of the directory.

Finally I tried a 2031 with DOS v2, and much to my surprise I was able to read the directory. However the output from the directory listing was not very pleasant:

0 "CMAR.D64         "    2A
664 BLOCKS FREE.

I know as much as an old 2031 drive would not come up with the D64 extention on its own, which suggests to me this floppy disk has been rewritten recently, probably a failed attempt of putting a D64 image onto it.

I read the same floppy disk in my 1541-II and once managed to bring up the directory listing as above. All other attempts lead to read error on track 18, sector 1.

Now I have two questions:

1. Does anyone know about this piece of software? Since there is a D64 mentioned, it suggests to me it should float around somewhere. I have some 46 GB of assorted Commodore stuff on my PC. While it is possible this file lurks somewhere within, it is a bit difficult to navigate. I have briefly checked Zimmers FTP, but no other respositories.

2. Would it make sense to dump the floppy disk block by block, hopefully without too many errors? I don't own any custom cables for nibbling purposes (G64 etc) but perhaps it is time to get one.

Frankly I don't know if this software is good for anything, but as my friend got almost the full package it would be nice if he/we got the last missing bit. He is looking to upload it to somewhere on the 'net anyway, unless of course it is already present at some place I didn't look and Google doesn't know to search in.

Yes, something like a PET-Switch (MBS-xxxx) but that one doesn't require a master computer to control the peripherals. Perhaps in a network the Teacher's PET could be used to allow or reject requests to print to avoid wasting paper.

Not only do you save a few bytes, you get much more logic into your program. A subroutine shouldn't jump back into middle of the program unless unavoidable. The main exception might be a program in which you constantly branch to one of many different parts, and they all have in common that the program should resume from beginning of the loop once the particular section is run.

Well, you can compact the line numbers:

10 REM PROGRAM
20 GOSUB100
...
100 REM SUBROUTINE 1
110 FORI=1TO20:PRINT"***":GOSUB200:NEXT
120 RETURN
...
200 REM SUBROUTINE 2
205 A=PEEK(32768)
210 ONAGOTO300,400,500,600
220 RETURN
...

While each line number itself will be stored as a two byte decimal number (0 - 63999), all references to a line number in GOTO and GOSUB statements are stored verbatim, as text. It means above we would have those strings "100", "200", "300" and so on in the listing. If the program is compacted to use as short line numbers as possible, you save space.

If you also reorder the program like this:

5 GOTO100
10 REM SUBROUTINE 1
...
19 RETURN
...
20 REM SUBROUTINE 2
...
29 RETURN
...
100 GOSUB10:GOSUB20

You will not only save memory (shorter line numbers in refences), the program will also run faster! This is due to Basic always starts from the beginning when it looks for a line number to jump to, whether it is a GOTO or GOSUB. If you place subroutines at the end, Basic will need to traverse the whole program to find it. If you place them at the beginning and use the GOTO trick to jump past the subroutines, you will make it execute faster.

There are a lot more tips like this. You could look for tips on VIC-20 and C64 Basics, since they use Basic V2 that to most part should be identical to PET Basic.

I don't have the answer, but somehow I think you can program the VIA to read a status register from the CRTC chip if present? I suppose on an older, non-CRTC PET you would get zero or garbage if it is possible to read the CRTC at all. This page - also by André - is fairly technical but it could be worth looking into.

http://www.6502.org/users/andre/hwinfo/crtc/index.html

The space between line number and statements is not saved in memory. It is only Basic's way to make the line more readable.

However if you write FOR I=1 TO 10, all the spaces are conserved and will take up valuable space. You may ask for a way to compact this kind of statement, which I am sure exists but don't know right now where to find. Usually Basic compilers were able to compact the program before compiling.

I can give away my "secret" right away.

Assume you have rooms 1, 2, 3 ... 19, 20. Usually when you define the map, the DATA statements look something like this:

10 DATA1,"THE LABORATORY",2,0,3,0,0,0
15 DATA2,"THE HALL",0,1,14,0,15,0
20 DATA3,"THE KITCHEN",0,0,0,1,0,0
etc

It would visually give us this map:
#  ___
# |   |
# | 15|
# |_UP|
#  _|_   ___
# |   | |   |
# | 2 |-| 14|
# |___| |___|
#  _|_   ___
# |   | |   |
# | 1 |-| 3 |
# |___| |___|
#

where each data statement consists of room number (perhaps not required), a description and integer numbers telling to which room you will be able to move. You will read all this into floating point or at least integer arrays, representing all data twice. In order to pack data somewhat, you can introduce an invalid room number -1 which means "end of room description" instead of filling up the DATA statements with trailing zeroes for all directions (north, south, east, west, up, down, in, out, special?) you can not move to.

The method I used instead was to convert integers to ASCII characters, using an offset like CHR$(33) # for room 0:

10 DATA1,"THE LABORATORY","%#&"
15 DATA2,"THE HALL","#$1#2"
20 DATA3,"THE KITCHEN","###$"

Indeed it means the routine which initially reads the DATA statements need to parse these map strings character by character which adds some overhead to the program. For a very small map it probably is not worth the trouble, but I found that for a somewhat complex map of 30-40 rooms and the ability to move in many different directions, in the end I would save perhaps a few hundred bytes at least.

As a bonus, anyone breaking into your program to LIST it and take advantage of the map will have a hard time parsing the DATA statements as they don't say clearly which room links to what.

Basic or machine code? I used to do a few homemade adventures and picked up a rather compact way to represent the map in DATA statements. Of course as you want to read it into an array, the compactness is lost at that point. Or maybe you will utilize a floppy drive - relative files? - so you don't need to keep all the game data in memory at once.