Umm.. Actually not. I just realized that the cs8900 doesn't have a scratch pad and the buffer can only be access in Memory Mapped mode, which unfortunately isn't available to us. Sorry!

I redesigned the logic to not use AEN, so I don't need it anymore for that reason, but it would be nice to have a unit known working, to test against. They are going to run the bare boards, mail me a few, and I'll hand solder one or two to ensure my layout works. Once that is done, I'll wire transfer the funds for the complete production.

Jim

You can use my NIC-Test tool to test chipselect and CS8900 functionality - it should have support for your board

So first I realised I was reserving 8KB of RAM and only needed 4KB, then Leif pointed out I could be using the 4K at $C000, then I realised if the RAM I'm using for the IP stack is that high, I can download stuff to the RAM underneath where the cartridge ROM is banked in at $8000 and then turn off the ROM (via the retro replay control register at $de00) just before executing the d/led prog and all in all, I can now download code anywhere up to $BFFF (which for a prg loading in to $801, means anything up to 47104 bytes long).

I'll shortly (tonight, family permitting) be uploading a new version including this change plus a "developers preview" of an API that downloaded programs can use to call ip65 functions contained within the cartridge, without needing to know the exact memory locations that the functions have been linked to. i.e. all functions are accessed by pointing AX at a buffer with parameters set in it, setting Y to a function number (1= DHCP initialisation, 2 = TFTP download, 3 = DNS lookup, etc), and then doing a JSR to $800d

Final PCB design has been sent out for production. Production of the boards will start Sunday night (Monday morning @ China) I should expect to see boards in 10 days. I am asking for 2 boards to be shipped ahead, and I will assemble here to ensure correct operation.

If all goes well, I will OK final production on April 16, and should have assembled boards in OH by second week of May.

If there is an issue, I will respin the boards, which will delay production a week or so (Obviously, I have checked the design over to minimize this risk).

Cartridge cases will be sourced from another vendor. I am recommending a clear case, so the LEDs need not be mounted. CCCC is considering a jig to mill cases for the cartridge.

I would like to offer the EPROM option at C4, but that depends on someone creating some 16kB cart images that can be loaded into the EPROM.

Jim

Congratulations! My pre-order will be on it's way as soon as I know what postage to .au will be



Well I'm pretty close to having a usable "netboot65" image that will fit the following in 8KB:
- a dhcp client that will initialize the IP stack via DHCP
- a tftp client (that will let you d/l and boot any prg up to 47K in size from a tftp server)
- an API that apps can use to access UDP functions, i.e.
- d/l a file via tftp
- lookup a hostname (or a "dotted quad" string like "192.168.1.1") to get the corresponding IP address
- listen on a UDP port
- send a UDP packet
- some helper functions for printing (e.g. to print an IP address, a hex digit or a null terminated string)

Was hoping to debug and upload this last night but a sev 1 at work took priority

A future release may add TCP functionality, but not in the very near term (unless someone else takes the initiative to add it ).

Given only 8KB of 16KB is used, it may also be possible to put a speed loader in, but that would require someone smarter than me to provide the necessary code.

BTW is it possible to turn off the ROM via software (ideally through the same mechanism used by Retro Replay to control GAME and EXROM, i.e. by writing a $02 to $de00?).

My understanding is that you can turn the ROMs off by setting LORAM and HIRAM in the $00/$01.

You should be able to write to addresses under the ROMs, so you can use the RAM under ROM, but the card is not smart enough to bank the ROMs out by itself.

Jim

The catch with that is from what I understand (by looking at the tables at http://codebase64.org/doku.php?id=base: ... management ) if you ghave a cartridge installed that is setting GAME to 1 and EXROM to 0, there is no combination of HIRAM & LORAM values that will give you BASIC at $A000 and KERNAL at $E000 and still have access to RAM at $8000.

The best you can do is set LORAM to 0 and HIRAM to 1 , so you have the KERNAL at $E000 but no BASIC which is a problem since 99% of prg's require BASIC, even if it's just a stub with a single SYS call.

I guess I could copy BASIC to the RAM under BASIC, then bank out the ROM and BASIC. Which would work for programs < 38911 bytes in size, at which point they will start to clobber BASIC. But then I guess if they're that big they are probably really pure M/L with a SYS stub, so I could just recognise that case and if the file is > 38K in length and a SYS stub is found, JSR to the address following the SYS, rather than jumping to BASIC.

Yeah, my concession was to copy ROM to RAM. You can always ask them to flip the switch on the cart tobank them back in, but adding more ICs on the board would have added cost for an item that was truly not a design goal per se.

Jim

I can understand that, and anything that keeps costs down is good with me.

One of the design goals I have for the "netboot65" api is to have something that will 'hide' differences in hardware so apps can be written that use IP without being tied to specific carts. I can see that the RR carts will allow apps to use a bit more RAM, so it seems the image I am developing for RR should use $de00 to bank itself in and out, but the image for NIC+ will need to use LORAM/HIRAM for banking. And it would be a bit rough for apps to have to try both banking mechanisms before trying to call a nb65 function, so I have added a feature where the cart will write a signature ( the string "NB65") to $c000, followed by a routine at $c004 that banks in the cart ROM.

That way a nb65 aware app can look for the NB65 sig at $C000, and if it finds it, jsr to $c004, and whatever type of cart the app is running on, the NB65 api will then be available to it.

Hi Guys! This is fantastic!. I almost missed knowing about the release date as the msg board never emailed me of new posts!

A few questions please?

- Couldn't see the price anywhere?
- Is this a complete unit with all switches, rotary switch, case, largest eprom etc included?
Or do I have to add stuff myself? (I would prefer complete).
- Is this production run an independent run to the Cincinnati Commodore Computer Club? If so how does it vary?

- Can I order a uIEC (latest SD version as well with it) ?
- Can the uIEC (SD) have the optional voltage regulator and still work form the cassette port for power?

Thanks,
Ken - vk4akp /
~Sj of `The RCC'~
http://shazam.zapto.org
.-.-.

I think CCCC is pre-ordering at $50.00

$50.00 is the NIC portion, but the EPROM socket and capacitor will be included. SWitches and the EPROM will probably be an upcharge.

No, I just did the design for the club.

Well, I am sure CCCC can arrange something, but it'd need to be special, since it's two different sales channels.

One or the other.

Jim

Updates:

• 102 PCBs have been manufactured and 2 are enroute to me for hand assembly.
• I have purchased enough parts to assemble 2 units here.
• Components have been ordered by the assembly house for 100 units.

I expect the parts and the boards to arrive here Tuesday. I will quickly assembly and test.

Best case: The boards work, and I will alert the assembly house to assemble and ship.

Worst case: The board design has an issue, and I will respin the board. Given the timelines, this might not change the delivery date, but it will cost $120.00-$240.00 or so to respin the boards, depending on whether a new stencil is required.

Jim

These are great news!!

I strongly advice you to test the carts on all different C64 and C128 board revisions before shipping. I dont know if it applies here but the MMC64 cart had some serious timing problems on certain models, especially the C128DCR if i remember correctly. I think there's an old thread about that here some where. Fortunately it could be fixed by reprogramming the CPLD.

Regrettably, I can only test with the units I have here, which is quite a ways off from "all". Jim