I must make this fix better by using an OR gate to feed this cut pi. Otherwise the "m" character looks ugly I will document this, but IEC cartridge first

Ladies and gentlemen, this is the first official release of the automagic & autostart IEC cartridge

The cartridge now installs IEC routines on boot, and displays an appropriate message. No setup / SYS calls necessary, just Plug&Play

The variables were moved into the top of screen memory, as I have a feeling that they're less likely to be overwritten there. So there go:

$FD7FF - status of current device (bit7=0 - present on IEEE bus, bit6=0 - present on IEC bus, bit5=1 - device status was overridden, bits4-0 - device number).
$FD7FE - status of previous device
$FD7FD - temporary variable
$FD7FC - bus overriding (bit7=1 - override autodetection, then bit5=1 - all devices are IEC, bit5=0 - all devices are IEEE, bit6=1 - all printers (device4&5) are IEEE).

If both bits 7 and 6 of device status are 1, then the device was not found on any bus. The device status will then be rechecked on next access. This allows hot-plugging of devices.

There's also a bonus for Steve, a fast RAM check on power on

Quote from: carlsson on December 17, 2010, 06:13 AMBy 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.

I have been looking for these connections for many hours over the Internet. Finally I found a shop which sold them. They were very cheap actually, I can try to locate it again for you if you need. I bought two for myself, so I also have one free.

Quote from: Steve Gray on December 17, 2010, 03:25 AM
It works with my MSD-SD2 as device 8 on IEEE, and the uIEC as device 10 on IEC! Nice.

This is great news - it means that autodiscovery works even with non-Commodore IEEE drives! Better than I expected

Quote from: Steve Gray on December 17, 2010, 03:25 AM
Which, brings up a question.. what exactly do we call this "cassette to IEC adapter cable"? It needs a nifty name... Should we settle on C2N2IEC ? Or, perhaps C2IEC, CX1541 or XC1541?

I'd opt for C2IEC for short... I don't like overly long acronyms, and the cable isn't just for 1541

It looks like your anti-spam system is blocking me most of the time to access the forum. Since I have a dynamic IP, this problem occurs irregurarly. So apparently you blocked a large part of Poland too...

Ah well, I found the answer here...

https://landover.ddns.net/cbm/index.php?topic=3551.0

Looks like nobody has the courage to test this code

I have been debugging it extensively yesterday. I removed a bug in the IEC code causing first IEC device access to fail. Unfortunately, the autodiscovery routine does not work with my IEC 1581, so I made some other workarounds to detect drives that don't exist on both buses. This removes the need to clear the device cache after connecting a new IEEE device.

I also added some settings variable to facilitate forcing all devices to be lEEE or IEC (thus disabling autodiscovery). All printers are IEEE by default, this also can be disabled.

The autostart cartridge code is also almost ready. It does not work on P500, as I don't have one to test, and VICE does not support it. I will release the code after Christmas, when I have some free time to polish it.

Browsing through Zimmers, i have found "DIN" kernals for C128, which were German localizations. So I highly suspect that this is also a German kernal.

More often than not when I visit this site, I am blocked by "403 Access Denied" errors. Sometimes I can view the site through my ADSL connection, but not via GPRS on my phone. Sometimes the other way around. The next day the problem disappears. Why this happens?

Sure, here is the kernal attached. When I have some time, I can play with a 6502 disassembler with it... But IEC has priority.

I got it from Austria. So the German localized kernal makes sense, especially that only the CRTC part is different. Pity that the character EPROM is dead. There's more code than in normal kernal (it fills all the portions normlly padded with $AA) so it might be indeed the code to handle the German keyboard.

BTW, the kernal is for high profile only. When inserted into 610, it still tries to initialize the CRTC with 8x14 characters.

Yesterday I was finally able to resurrect my 720 I pulled a strange kernal from it, labeled "324866-03A Kernal DIN". Comparing it to a normal kernal, it shows that the video section at $E000-$EE00 is vastly different. But the kernal boots in VICE normally. I was wondering, what kind of kernal is it?

There was also "324867-02 Character DIN" in the character ROM, but the EPROM did not survive and I wasn't able to read its contents. Since the character ROM was different, maybe it means it was some localised version?

Quote from: Blacklord on December 08, 2010, 05:31 AM
Unfortunately I don't speak German - does this guy post internationally ?

I asked him and he confirmed to ship internationally, including US and Canada.

Would be great to know how it works with different devices. Especially the IEEE detection routine, as I've never seen before anybody doing such thing so I don't know whether I got it right

Yes, he agreed to ship to me to Poland. He speaks very good English, BTW

He also has lots of bare 700 motherboards, unfortunately all socketed chips are stripped.

And the keyboard is mine

The seller seems to have lots of keyboards available, perhaps from some liquidation?

Yikes, I found it!

http://cgi.ebay.de/COMMODORE-CBM-TASTATUR-700-SERIE-Raritat-/170570864520?pt=Klassische_Computer&hash=item27b6d0d788

Now please nobody outbid me! 

Quote from: Hydrophilic on November 21, 2010, 07:36 PM
Slightly off topic: my friends (especially girl friends) tell me I need to get a cell phone and I tell them nobody makes one good enough for me!  I would like something which is easy to program / open source... like Android maybe? but which is also good for gaming, like photo below.

Any suggestions?  Please nobody recommend iPhone.  Touch screen sucks for games!!!  Need real d-pad and game buttons.  Thanks again!

Maybe Palm Pre? It's also open source / Linux. It has also a very nice gaming 3D library. I have played some 3D games and they were impressive. The only phone that can compete with Palm WebOS games quality is the iPhone.

And you could write a Commodore emulator for it, I would definitely use one

This is the second cartridge revision. It should support automatic device type discovery. So now it is possible to use IEEE and IEC devices at the same time!

SYS 24586 - disable IEC
SYS 24589 - enable IEC/IEEE

How does it work? When a device is first accessed (by KERNAL routines TALK and LISTEN), the cartridge tries to find it on the IEEE bus, by trying to open some file on it. If opening the file does not yield the error "Device not found", the device is thought to be present on the IEEE bus. Otherwise the device is supposed to be found on the IEC bus.

The device status is cached in memory at $F03FF. The first 4 bits contain the device number (4-15), and bit 7 indicates IEEE status (0 - device is IEEE, 1 - device is IEC).

All subsequent accesses to this device will look at this cached status variable and choose appropriate routines (IEEE or IEC). This way device status needs not to be rechecked every time.

There is also another status variable at $F03FE, which holds status of the previous device. This way, for example, you can copy files from one drive to another, and the cartridge remembers status of both devices without the need of constant rediscovery. Only when you try to access a third device, the first status is thrown away - so the cartridge always remembers the status of two last accessed devices. This speeds up operations that require using two devices at the same time.

This scheme may have an unplasent side effect - if you try to access a nonexistent IEEE device, the cartridge remembers its status as IEC. So even after you plug it in, it still will be inaccessible because the cartridge will look for it on the IEC bus according to the cached status. You can clear the statuses, for example, by trying to access two other devices (like 14 & 15) so that status variables are cleared. This is something I will need to look at in the future (for example, by attempting discovery also on the IEC bus).

I have checked the cartridge briefly with my 8250LP and 1581. It works fine - I can access both devices at the same time, without the need of any manual configuration! I can open files on both drives simultaneously, read/write from them etc. I would like to hear about your experience, and what drives you were using.

Note: variable at $F03FD is used as a temporary scratchpad for the routines. Also, I have no idea how the autodiscovery routine would work on IEEE printers, as they differ significantly from disk drives. I don't have any IEEE printer to test.

Now I am going to work on autostart routines. Plus buy an EPROM eraser, as I used my last EPROM on this one

Reading from the command channel is a nice idea. But if another program has already opened channel 15 for reading, this again will mess up with the device state.

But I have finally come up with a solution:

1. Scan the open files table to find an unused channel on a device (a channel that has no file open). There can be less than 15 files open, so you are guaranteed to find a free channel.
2. Open a file with this channel and filename "#9". This will try to read DOS buffer number 9, which of course does not exist (there are only at most 5 DOS buffers).
3. If the device does not exist, kernal status variable will have bit 7 set (device not present). If the device exists, this bit will be 0.

This procedure guarantees that the device state will not be disturbed (we are using a nonused channel, and nonexisting file). Using a DOS buffer name also ensures that the drive will not try to read from disk searching for a file. And using a nonexisting DOS buffer guarantees that we are not messing up with someone's data.

This has worked with my 8250. I think it should work with all other drivers (don't know about printers, though).

Well, the problem is I need to do it in a kernel overaly. So:

* I cannot disrupt the state of the computer in any way. Therefore I cannot open/close any files on the computer.
* I cannot disrupt the state of the drive in any way. So I cannot send commands to initialize it.

I am trying to find out the easiest way to discover whether a given IEEE device (let's say: a disk drive) exists, from an assembler code.

I have been thinking that simply sending a TALK or LISTEN command to a non-existent device would result in some value of "Status" variable that would tell me that the device is not present. But it's not the case. I need to actually read something from a device, and only then the ACPTR command sets the "Timeout" bit in the status variable if the device is not there to send anything.

So the correct way would be to make a device actually send something to the computer. But I am not that proficient in the low-level details of the IEEE interface, so I don't know how to prepare the device so that it sends me something. I guess I need to call LISTEN and SECOND, tell the device that I need something from it, then TALK and TKSA... but with what parameters? I have no clue. I would appreciate any help.

Looks interesting, and I think it would do the job.

But... maybe I am blind, but I can't see any download link, where I could download the controller firmware source code?

Yes, I saw the matrix But I never heard of C=Key, where can I find information about it?

Well, I must support the B256, since I have myself upgraded my 610 to 256kB RAM and BASIC 256 But I guess that the P500 could easily be omitted.

I want to make the interface so that no switching/enabling/disabling is required. That is, it should work totally automatically. First I thought of making a device mask just like you suggested. But now I think it can be made easier.

Every bus transmission must begin with TALK or LISTEN. So with these operations, I will call IEEE routines first. If the device responds, I will set the flag "Current device is IEEE", and all further operations will use IEEE routines until next TALK/LISTEN. If not, I will call the IEC routine. If the device responds, I will set the flag "Current device is IEC" and all further oeprations will use IEC routines. If no device responds on either bus, I will set the status variable accordingly and exit.

ID remapping is a very neat idea (although my 1581 has nice switches to select the device number ). But I would need to learn how to write BASIC wedges and dedicate some RAM area for the remapping map. But it is definitely worth looking into.