As well, I tried to submit the patch for inclusion, but Ingo would like an email from Hydophilic for legal reasons.

Jim

abraXxl, thanks for the patch against HEAD.  I was planning to try to merge the changes into HEAD this weekend, but you beat me to it.Jim

Quote from: Hydrophilic on March 02, 2011, 02:44 AM
I LOVE IT!!!!          It's not perfect, but if you don't like it, byte me!

Did you make your changes against the newest source in Ingo's GIT repo?

Jim

BTW, note that the uIEC has a Google Group Mailing List:  'uIEC-users'  You might want to join if not already on.

Jim

Quote from: abraXxl on February 28, 2011, 07:07 PM
If you replace the AtMega644 with the pin compatible Atmega1284 in the LarsP/MMC2IEC this not true anymore. It has 128kb flash memory, too.

I limited my comments to something almost everyone can do.  Yes, if you replace the uC, all things are possible, but doing so implies the user has a programmer and potentially can solder (some of the MMC2IEC variants are surface mount.

Quote
The bootloader scans for files in rootfs with a specific size. For LarsP/MMC2IEC/Atmega644 the size is 61440 bytes and for uIEC/1281 and Larsp/1284 it is 126976 bytes. To ensure that the devices stays functional a specific hardware id is also encoded in the flash file, the version is also compared. The new to be flashed firmware version must be newer than the old.

Since we're clarifying, it is not completely true the version must be newer.  Versions of 0.0.0.0 will overwrite anything in the flash, assuming the CRC is different than the image already on FLASH.  This is how we create development images.  The Makefile will take care of this for you if you simply uncomment the line adding "PRE" to the version string.

Quote
I like the way the XR: command works for rom images. So here my idea. The command XC: is free (e_X_tended commands _C_128 bootsector). XC:filename. If sd2iec firmware is in native filesystem mode and track,sector 1,0 is requested the first 256 byte block of the file is sent. The file is firstly searched in current directory and then in the root filesystem. This way you could also implement longer sector chains to be read as bootsector. Just send the following 256 byte block of the file are send.

:wq

I'm leery of providing that much flexibility.  I'd rather use the "boot.img" naming in the code, looking for it in the dirs as you indicate, and then see who finds that approach too inflexible.

Why?

XR was added because a user, rightly so, might need to run multiple ROMs during the course of a session.  -XR was an easy way to add that to some code, so folks could do:

1 open15,10,15,"XR:...."
...

and ensure their application worked.  I'm not convinced folks need that level of flexibility in a boot record.  It's typically used once per computing session.

I'm happy to be wrong, but I think it is more prudent, given the scarcity of EEPROM locations, to start with my approach. If there are feature requests to apply more flexibility, at least we know there is a large enough user base to allow the additional feature.

Jim

Quote from: Hydrophilic on February 03, 2011, 04:47 AM
Using a sector editor, I modified the MBR to have a second partion.  I also modified the boot record of the first partion to be smaller and added a second boot record for the remainder of the memory card.

Egad, kinda scary.  I'd recommend using "Windows Enabler" and then you can use the grayed out features in Windows NT.

Quote
Okay, so maybe Win2K drivers are out-of-date (it is 2011 by now), so lets give WinXP a try... Long story short: WinXP does the same crap... I don't have (an intend NEVER to have) WinVISTA.  Still debating Win7...

Windows NT-7 does not allow multiple partitions on removable cards.  In fact, the MBR stuff was added to the sd2iec codebase because uIEC supports HDDs (uIEC/IDE), which can have multiple partitions.  It will support up to 15.

Quote
Good news!  Both partitions show up with $=P, I can change to either partition with CP, and the files I copied (using Win ME), all show up.

As the author of the $=P code, I'm glad you found it useful.  It took some time to make it work correctly.

Jim

uIEC supports SRQ line.  It was designed into the project in anticipation of eventual fast serial support.

The larger issue with this added firmware support if the firmware image size.  Currently, the sd2iec firmware is approaching 60K, and only uIEC (with 124K of firmware space) can hold larger firmware images.

Jim

Quote from: abraXxl on February 23, 2011, 09:34 AM
Well, nice to see some progress here

Are the patches avaiable for public testing and does Unseen Pull them into his git-Repository? Are in contact with him, so that patches don't get lost.

What is the AVR pin you used for SRQ.
I have 3 of these PCBs - called LarsP layout with Atmega 644/1284 running SD2IEC Firmware. I would happily test and adopt this to LarsP layout.

Sadly, LarsP does not support the SRQ line, but maybe you can solder a wire to the correct pin and update the firmware defines to add support for the pin.

Quote from: Hydrophilic on February 23, 2011, 05:53 AM
Now there are several devices that use the SD2IEC firmware, but I only have a uIEC to test with.  (I recommend it by the way.)  When you issue a Directory command, the funny thing about the device is that it lists the file size in terms of FAT clusters... definately not the same (often MUCH larger) than a standard CBM "block"...

Correct, though if you want to have it report BLOCKs, you can modify the code in fatops.c:fat_freeblocks().  return clusters should be switched to return freeblocks * 512/ 254 to be perfect, or freeblocks * 2 to be close enough.  if you do change it, ensure you change the if statement so the maximum value returned is 65535.

If you're planning to implement the boot sector in sd2iec, please let me know.  It would be best to implement it two different ways.  When not in an image, it should load a boot.img file in the root directory, or something like that.

Jim

Quote from: Hydrophilic on February 03, 2011, 05:58 AMI only have a uIEC/SD to test this with, but as I understand the same firmware is used with MMC2IEC... also my main reason for this effort is for much improved Media Player performance, but it should benefit the C128 community in general... in particular CP/M should be possible at "fast" 1571/81 speeds instead of the pathetic 1541 speeds...

The firmware, at one point a year or so back, would still fit in the MMC2IEC hardware, but no longer.

Quote


Really bizarre if you ask me!  I see no reason why I can't compile source code with DOS (or CP/M if I wanted to do so)... well if the vendor sucks, go to the open-source community!  WinAVR was my next option and it runs fine on both Win 9X and Win NT.... (see notes below)

Well, I wouldn't call that bizarre.  Win98 hasn't been supported by mainline toolchains for some time.  I am surprised WinAVR supports it still.

Quote
Another important thing is that neither WinAVR nor the uIEC source code includes "CRCGEN-NEW" binary.  This is critical for updating the firmware of the uIEC (maybe MMC2IEC also).  It appends a CRC checksum to the binary so the firmware will accept and update the EEPROM.  I found a copy here, but haven't tested it yet.  (The last link seems to be the official SD2IEC "site")

Hmm, I'll consider adding it to the files...

Quote
Also strange about WinAVR is it seems to (re)install a complete POSIX-style build environment.  I have been using Cygwin and MySys for several years now to build Unix / Linux style binaries for Windows, so don't really see why I'd need to install another copy of cygwin.dll and all the other binaries... 

It does that because, it can't depend on your copy being new enough, and it can't depend on it already being installed.

Quote
Anyway, I just thought toss out my experiences thus far and ask for any/all opinions regarding firmware builds for uIEC / MMC before I brick my own hardware... thanks!

It is impossible to brick the uIEC by loading new firmware via the SD card :-)  Hack away!

Quote from: DotBoy on January 10, 2011, 02:05 PM

Quote from: brain on January 08, 2011, 01:31 PM
C128 mode is jsut for the EPROM, not for the NIC itself.

Jim, could you expand on that a little bit? Like the op I've been flipping the switch to then 128 setting when using the Contiki 128 web browser, for example.  Are you saying that isn't necessary?

I'm probably missing something obvious and I'm sorry for being thick, but I don't really understand what you mean by that.

It is not necessary.  The switch's full name is:  "C128 EPROM Mode".  The definition is:

"When EPROM switch is on, this switch configure the EPROM for C128 mode (i.e., do not pull EXROM/GAME low).  When EPROM switch is off, this switch has no effect.

It was added to ensure that the NIC EPROM wasn't a C64 only thing. 

There is another feature on board the PCB.  Right around the C128 EPROM switch, there is a 2 position jumper.  If you cut the trace an d solder the other half closed, the C128 EPROM mode will track the low bit of the hex switch.  Thus, instead of having:

ROM bank 0
1
2
3
4
...
16

You have:

C64 ROM bank 0
C128 Bank 0
1
1
2
2
...
8
8

(It's just tying the state of the GAME/EXROM lines to the state of the low bit of the hex switch).

The advantage is that you could put the 64 Telnet in C64 bank 0, the C128 version in C128 bank 0, and select the telnet client by just rotating the switch.  Of course, you have to leave the EPROM switch inactive for this to work)

The EPROM stuff was just added to the NIC because it seemed a waste of space to not include something in the blank area.  It is not needed.

Funny, though, I get no questions on NIC operation, it's the EPROM stuff that generates all the questions :-)

Jim

C128 mode is jsut for the EPROM, not for the NIC itself.

I have heard that some folks have bus issues with the NIC.  Can you reduce the number of variables and see what works.  I'm happy for a return if you can't get it to work, but the fact that NIC-Test works seems to indicated a lack of bus issues.

Push all the switches away from the cart port.  That will enable 64 AND 128 mode operation.

Jim

Push all switches so the ends are farthest from the cart port connector.  That will configure for 64 AND 128 mode.

Jim

What about 64NIC+ in Std mode?
64NIC+ at alternate base address? :-)
64NIC+ at alternate IO base?

Jim

Payton, I think it would be useful to consider an ncurses-like library for apps like this.  CONIO is very limiting, as has been noted, and a cross platform screen-based IO library would still provide a high degree of portability (And, cc65 would love a cross-platform library like that, and maybe already has one that can be used or augmented.  I think supporting a new primitives (write at position, clear screen, scroll up/down/left/right) would provide lots of value to many applications.

Jim

Quote from: MIRKOSOFT on May 10, 2010, 02:14 AM
Thank you very much, but else one Q is here - if I understand correctly:
For C128DCR I need ROM only for computer (don't want JD for C1571-built-in).I have else one computer C128 standard, so:

Need I only two C128 ROMs?
And one JD ROM for C1581? (this I'm using with standard C128)
Will be sure that JiffyDOS will work in C128 and also C64 mode?

Thank you very much for helping me.


Miro

The C128DCR is a single ROM, but it contains the 64 and 128 KERNALs.
The C128 is a 2 ROM set (It's a package containing the C64C ROM and a C128 mode ROM).

Normally, we don't sell partials, but if you want just a 64 ROM for the C128, order a C64C JD ROM (that's what the C128 uses).  If you want the C128DCR KERNAL only, you'll need to order a C128 ROM set (to charge the right price) and note you want just the C128DCR KERNAL in the comments of your order.

Jim

Most 1581 units have the ROM socketed.  It should be a quick pull and replace.  No switch.

--

Jim
http://www.jbrain.com

If this is not the person who conversed with me Friday night, note that someone is working on a 4 port serial switcher PCB.  Seems we should just do this once.

Jim

I can also burn a new CMD HD ROM if needed.

Jim

Quote from: cbmguy on February 14, 2010, 08:26 AM
Hi,

I've been looking all over the place for info about this and I keep getting the same exact spec's -- cut and paste....   While the unit says it 64 and 128 compatible, I have no idea what that means; 128 mode compatible?  Is there any users out there that might know this?  Is it compatible with the 128 as in c64 mode?

Thanks,

C

The unit is 128mode compatible, but I am not aware of any C128 SW for the CS8900A IC in the unit.  Th ROM socket is also C128 128 mode compatible (the ROM will show up in both external ROM locations), but there is no SW to take advantage of it as yet

Jim

Trying to fill a small gap, I'm working on a 3 slot expansion port solution ala EX-3 or FB-EX3.  Here is a first cut of the PCB design:

http://www.jbrain.com/vicug/gallery/xpansion/ext3_d

Comments are appreciated.  Some things I'm curious about:

• Is the switch location OK, or do people need them off to the side?
  
• Does anyone want a top slot for the 3rd slot?  or is the back entry desired?
  
• Any other features besides the existing ones that are desired?
  

Jim

If desired, I can link to the projects from the JiffyDOS site (for those who want to try before buying, etc.)

Let me know.

Jim

Quote from: Hydrophilic on January 06, 2010, 02:51 PM
Putting this in a ROM image is very gray indeed.  For one thing the author of JiffyDOS did a fine job and I don't want to be robbing him (or those licensed to sell JiffyDOS) of anything.

As the licensee, I appreciate that :-)

Quote

However the software is original, not copied.  What I did was use VICE to see what JiffyDOS was doing, and how many cycles were used, etc. and made a ton of notes.  Then I wrote the source by referencing both the C128 KERNAL code and my notes.  In particular, reconstructing the 16 byte table used to trasmit bytes based only on my notes was a bit tricky...

Then, I think you are good to go, then.  However, I think the VIC port and the 64 port need to be rewritten to use your code, since I understand the original 64 routines were just lifted from JD.  I know you're not planning to do it, but I hope someone reads this and takes care of this issue.

Quote
I also recently noticed that single byte transmission (or was it reception) is not checking for device time out.  Since neither the VICE emulated JiffyDOS device nor my uIEC ever had time-out errors, I didn't realise this until I decided to compare my code with JLOAD (64).  The fix would require 4 bytes as I recall and should still fit in the segmented memory configuration I came up with.  By the way, I had to do some crunching to get it to fit in the first place, which should be appearant if you read the source.

Is the error check not done in the original JD as well?  If so, could I trouble you to explain it to me?  I am looking for ways to improve the product (fixing bugs, mainly) and this would help.

Jim

One thing I would recommend is to reimplement SJLOAD64 functionality using this codebase.  I know the original author of SJLOAD, and he mainly intended it as a proof of concept, not a shipping product. 

Quote from: Hydrophilic on December 19, 2009, 09:16 AM

As I understand it, you can get JiffyDOS from Jim Brain's storefront.  However looking at the site, it seems these are just images of the firmware, not actual (EP)ROMs that you can plug into your C128.

The ROMs are available ($35.00 for the C128 set, $40.00 for the C128D triple set, $20 for other ROMs).  I will put them in the storefront pronto.  People can PM or email for more information.

Note that SJLOAD sits in somewhat a gray area of copyright.  Unless the core transfer routines have been modified since I last saw them, they are almost identical to the copyrighted JD ones. 

Personally, I don't see an issue with SJLOAD, due to the target audience.  Many gamers and other users who just want decreased load times would never consider buying a JD, so I don't see any overlap.  Obviously, with a limited functionality, there's a natural stepping stone to an actual JD ROM overlay.

This code, though, is sliding into a no-man's-land concerning the copyright.  I can't use my "It's only the LOAD function" defense if the copyright holder protests. 

As I'm not the copyright holder, and it's not a pirated ROM image, I don't have any clear direction on this, but folks might want to consider ensuring the functionality stays a bit more limited.  Note that I'd give the same advice regardless of my licensee status, for what it is worth.  I think if only loads/gets were supported, I could continue to use my "load" defense if there is a protest.

As well, my apologies for not seeing this thread earlier and helping with information.  I check this forum on a regular basis, but I use the "unread" link to quickly scan new messages, and this thread did not (and does not) show up on that search.  I have no idea why.

Jim

Quote from: SmallCleverDinosaur on February 09, 2009, 05:29 AM
Robert, do you know if Jim works together with NKC Electronics since they use the same firmware?

I mailed Tony and he told me that the SD2IEC will work in native C128 mode. Though he didn't say if it would support burstmode or not.

SD2IEC will not do burstmode, as it uses the same firmware.

My apologies for just now seeing this.  (It's best to email me for specific questions).  I do not work directly with Tony, but we do both use the same firmware.

Jim