1541 Ultimate Plus with 32MB REU!
Nicolas Welte
The 1541 Ultimate will also be available with a 32MB SDRAM chip that is
used to emulate a Commodore REU with 16MB RAM!
The features of the cartridge are very impressive:
- 512kB SRAM
- 4MB Flash Rom
- 32MB SDRAM (only on the Ultimate Plus)
- SD card Interface
- AR and FC3 cartridge emulation
- file browser to select disk images and DMA-load PRGs
- fully compatible 1541 emulation
- fully compatible REU emulation with up to 16MB (only Ultimate Plus)
- file browser also works in C128 mode for disk image selection!
The price is Euro 99 plus shipping for the 1541 Ultimate, and Euro 119 plus
shipping for the 1541 Ultimate plus.
You are encouraged to send your preorder now, so Gideon can order
components appropriately.
some more info:
http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm
There's also a news article on retrohackers and a discussion thread:
http://www.retrohackers.com/news.php?news_id=26
http://retrohackers.com/forum/viewtopic.php?p=2227#2227
(you can PM or post your preorders to Gideon there)
some more discussions in German:
http://www.forum64.de/wbb3/index.php?page=Board&boardID=204
If you want to preorder, and have trouble reaching Gideon, just mail it to
me, and I will forward it: 1541ul...@x1541.de
Nicolas
www.x1541.de
christianlott1
this.
MagerValp
c> i'd like to know that G64 images work before i order something like
c> this.
Why? Is there anything out there that doesn't run from plain d64s?
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
christianlott1
> >>>>> "c" == christianlott1 <christi...@yahoo.com> writes:
>
> c> i'd like to know that G64 images work before i order something like
> c> this.
>
> Why? Is there anything out there that doesn't run from plain d64s?
you're joking. there are plenty of games that load as g64 but not d64.
Wolfgang Moser
christianlott1 schrieb:
> i'd like to know that G64 images work before i order something like
> this.
as Gideon's website states, currently D64 and T64 files
are supported. Please read the section "1541 Drive
Emulation" here:
http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm
Until Gideon tells explicitly that G64 files are supported
by the 1541U, you really should consider G64 image files as
being _not_ supported. You may check his webpage regularly,
if the specs change sometime.
Womo
iAN CooG
>>>>>> "c" == christianlott1 <christi...@yahoo.com> writes:
>
> c> i'd like to know that G64 images work before i order something like
> c> this.
>
> Why? Is there anything out there that doesn't run from plain d64s?
yes, not very common to find but there are many "cracks" (well, not really)
done just by introlinking originals, that needed nibbler copiers anyway.
FinalAssault/DanishDreamLine and FinalAssault/Lazer are only the latest I
found having this problem =)
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
MagerValp
MV> Why? Is there anything out there that doesn't run from plain d64s?
IC> yes, not very common to find but there are many "cracks" (well,
IC> not really) done just by introlinking originals, that needed
IC> nibbler copiers anyway. FinalAssault/DanishDreamLine and
IC> FinalAssault/Lazer are only the latest I found having this problem
IC> =)
Not handling a few bad cracks is hardly a showstopper though,
especially when you can run the excellent crack from n0s.
MagerValp
MV> Why? Is there anything out there that doesn't run from plain d64s?
CL> you're joking. there are plenty of games that load as g64 but not
CL> d64.
All of Gamebase runs on d64s. Which games are you talking about?
Peter Dassow (remove the NOSPAM. for direct answer)
> Please read the section "1541 Drive Emulation" here:
>
> http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm
>
> Until Gideon tells explicitly that G64 files are supported
> by the 1541U, you really should consider G64 image files as
> being _not_ supported. You may check his webpage regularly,
> if the specs change sometime.
Wolfgang,
do you know if the Z80 cartridge with that crude C64-CP/M 2.2 system is
working with the 1541U ? I mean, the CP/M bios itself uses also IEC
commands without any special tricks (so far I know).
It should work if the 1541U is communicating with the C64 like the
original drive (for sector read and write, that's almost all what the
CP/M is using, the rest (logic) is done by the operating system itself)...
Regards
Peter
--
* Try http://www.z80.eu for CP/M computer and software infos.
Pheuque
> You are encouraged to send your preorder now, so Gideon can order
> components appropriately.
>
> some more info:http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm
>
> (you can PM or post your preorders to Gideon there)
Looks very interesting. I would like to see support for D71 (360k 1571
Disk images) and D81 (1581 Images), as well as a native format that
can handle 16MB.
My main need for an REU is GEOS support, so I would to know how this
works with GEOS.
hg
"Pheuque" <Ratt...@gmail.com> wrote in message news:8919c44c-c59f-4e9a...@z26g2000pre.googlegroups.com...
>
>> You are encouraged to send your preorder now, so Gideon can order
>> components appropriately.
>>
>> some more info:http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm
>>
>> There's also a news article on retrohackers and a discussion
>> thread:http://www.retrohackers.com/news.php?news_id=26http://retrohackers.com/forum/viewtopic.php?p=2227#2227
>> (you can PM or post your preorders to Gideon there)
>
> Looks very interesting. I would like to see support for D71 (360k 1571
> Disk images) and D81 (1581 Images), as well as a native format that
> can handle 16MB.
Wouldn't that require someone to write an FPGA implementation of the 1571 & 1581 drives?
Pheuque
> Wouldn't that require someone to write an FPGA implementation of the 1571 & 1581 drives?
Probably, if you wanted it to work with any Copy Protected 71/81 disk
images... but I think they are SO rare, you could probably get away
with the more generic 1541 emulation if you matched the track and
sector layout.
I only vaguely remember one CP'ed 1581 and about 5 1571 disks that had
Copy Protection, with no clue as to what they were.
The 81 version would also need to support subdirectories.
christianlott1
> >>>>> "CL" == christianlott1 <christianlo...@yahoo.com> writes:
>
> MV> Why? Is there anything out there that doesn't run from plain d64s?
>
> CL> you're joking. there are plenty of games that load as g64 but not
> CL> d64.
>
> All of Gamebase runs on d64s. Which games are you talking about?
you're right and that's a good call - however, i prefer to boot
original disk images (g64). cracktros and 'ass presents' on every disk
is not my idea of a good time :)
Wolfgang Moser
Peter Dassow (remove the NOSPAM. for direct answer) schrieb:
> do you know if the Z80 cartridge with that crude C64-CP/M 2.2 system is
> working with the 1541U ? I mean, the CP/M bios itself uses also IEC
> commands without any special tricks (so far I know).
> It should work if the 1541U is communicating with the C64 like the
> original drive (for sector read and write, that's almost all what the
> CP/M is using, the rest (logic) is done by the operating system itself)...
sorry, but I don't own a 1541U yet, so I'm unable
to test things. From reading the specs only I'm
unable to decide, if there're chance that this
will run.
If you want to use the 1541 emulation part only,
well then it really should work since the
emulation does emulate the hardware. DOS Kernal,
registers and all that is just the same as with
a standard 1541. But if you want to use the
cartridge options in parallel, well, this may be
a hot candidate for incompatibility issues.
From the pictures there you can see that the
1541U does not come with an through-out port, so
for sure you would need some expander card. Or
you need to use the 1541U in standalone mode,
omitting the imgae file browser.
Womo
Peter Dassow (remove the NOSPAM. for direct answer)
> [...]
> If you want to use the 1541 emulation part only,
> well then it really should work since the
> emulation does emulate the hardware. DOS Kernal,
> registers and all that is just the same as with
> a standard 1541. But if you want to use the
> cartridge options in parallel, well, this may be
> a hot candidate for incompatibility issues.
>
> From the pictures there you can see that the
> 1541U does not come with an through-out port, so
> for sure you would need some expander card. Or
> you need to use the 1541U in standalone mode,
> omitting the imgae file browser.
Thank you for your answer, Wolfgang. So far I understand that it's
impossible to use the 1541U just as a real-1541-drive-replacement,
because you have to set up first all relevant parameters (what image
should be used a.s.o.) ?
Also, even if the 1541U is able to emulate a real drive, how should I
change the floppy-disk-image if I am not using the designated user
interface ?
John
> you're right and that's a good call - however, i prefer to boot
> original disk images (g64). cracktros and 'ass presents' on every disk
> is not my idea of a good time :)
>
I think you're spot on there Christian. I hate all that nonsense also. I
always think that anyone who insists on telling the world about their
"handiwork" is lacking in something or suffering from an attention
deficit :)
In saying that... some of these "cracktros" are technically impressive.
Still, no need for "Hi to all these cool doodz.....".
Wolfgang Moser
Peter Dassow (remove the NOSPAM. for direct answer) schrieb:
> Wolfgang Moser wrote:
>
>> [...]
> > If you want to use the 1541 emulation part only,
>> well then it really should work since the
>> emulation does emulate the hardware. DOS Kernal,
>> registers and all that is just the same as with
>> a standard 1541. But if you want to use the
>> cartridge options in parallel, well, this may be
>> a hot candidate for incompatibility issues.
>>
>> From the pictures there you can see that the
>> 1541U does not come with an through-out port, so
>> for sure you would need some expander card. Or
>> you need to use the 1541U in standalone mode,
>> omitting the imgae file browser.
>
> Thank you for your answer, Wolfgang. So far I understand that it's
> impossible to use the 1541U just as a real-1541-drive-replacement,
this is not correct, sorry that I put you in a
wrong direction. This is not mentioned on the
webpage, but even in standalone mode you're able
to select images via IEC bus commands. This is
what I read from an early tester in a german
CBM forum.
> because you have to set up first all relevant parameters (what image
> should be used a.s.o.) ?
I really don't know how this exactly works out,
but it's not impossible to use the 1541U as
standalone replacement.
> Also, even if the 1541U is able to emulate a real drive, how should I
> change the floppy-disk-image if I am not using the designated user
> interface ?
I don't know, there're some button that have
got special meanings in standalone mode.
Womo
MagerValp
>> Wouldn't that require someone to write an FPGA implementation of
>> the 1571 & 1581 drives?
P> Probably, if you wanted it to work with any Copy Protected 71/81 disk
P> images...
No, you're missing the point here. As the 1541U is compatible with
fastloaders, it's also bound by the same limitations as the original
1541. It's really just a 1541 with the 5.25" mech replaced by an SD
card slot, produced with modern components. Making the 1541U support
d71 and d81 images is nearly as hard as making a real 1541 read larger
capacity disks.
cybe...@web.de
> fastloaders, it's also bound by the same limitations as the original
> 1541. It's really just a 1541 with the 5.25" mech replaced by an SD
> card slot, produced with modern components. Making the 1541U support
> d71 and d81 images is nearly as hard as making a real 1541 read larger
> capacity disks.
Thats not true. The 1541 is emulated by an FPGA. You could write a
1571 or 1581 emulation as well. There is just not enough space in the
FPGA to emulate all the drives at the same time.
The module emulation is the same. By choosing the right image you can
have a AR or a FC3 cartridge. You cannot change it on the fly while
working.
You can flash the image you want to the flashmemory or you just put
the image in the root of your SD-card and it will be loaded on
startup.
The standalone mode is not impemented yet. There are three buttons
that could be used and there will be commands maybe like
"open1,8,15,"cd:..." to controll the 1541U through the IEC-bus. We
have to wait till it is ready to know it exactly.
Cyberdyne
Wolfgang Moser
nice to meet you here ;-),
cybe...@web.de schrieb:
>> No, you're missing the point here. As the 1541U is compatible with
>> fastloaders, it's also bound by the same limitations as the original
>> 1541. It's really just a 1541 with the 5.25" mech replaced by an SD
>> card slot, produced with modern components. Making the 1541U support
>> d71 and d81 images is nearly as hard as making a real 1541 read larger
>> capacity disks.
>
> Thats not true. The 1541 is emulated by an FPGA. You could write a
> 1571 or 1581 emulation as well. There is just not enough space in the
> FPGA to emulate all the drives at the same time.
we better do _not_ expect anyone to write such FPGA
cores and do live with that what comes out at the
beginning. This is what we've learned from all the
other FPGA projects out there. Although 1571
emulation would not be very much to add to the
existing 1541 emulation, it would need a whole new
loop of testing all the function blocks and so on.
What I would like to see would be parallel cable
support in a way that the free VIA port within the
emulated 1541 is connected to a dedicated VIA, CIA
or PIA like port at the C64's expansion port. And
that one should also be a virtual one as well as
the parallel connection itself. That way easy
parallel speeders would only need some patching
of the C64 kernals, so that the parallel port is
looked up in the expansion port area rather than
at the user port. Even copy tools like
Burstnibbler should find the cable there due to
their autodetcion schemes. Just an idea for
further extensions, when the basic work is done.
> The module emulation is the same. By choosing the right image you can
> have a AR or a FC3 cartridge. You cannot change it on the fly while
> working.
> You can flash the image you want to the flashmemory or you just put
> the image in the root of your SD-card and it will be loaded on
> startup.
>
> The standalone mode is not impemented yet. There are three buttons
> that could be used and there will be commands maybe like
> "open1,8,15,"cd:..." to controll the 1541U through the IEC-bus. We
> have to wait till it is ready to know it exactly.
Thanks for correcting me, I got the impression as
if standalone mode was fully working yet.
Womo
Pheuque
for as the controller is concerned is the number of tracks, and where
the BAM/Directory info is stored.
Since it's only reading from D64 files, there isn't any emulation of
timing from read/write heads, or other more esoteric disk protection
techniques.
It's just a block for block/byte for byte image that is being
presented to the FPGA controller as if the information was coming from
the disk.
Given that there is no REAL media, or drive mechanism, it's a matter
of reprogramming the controller what to expect. The controller is most
likely a 6502 with 4-8K of memory. Reprogramming this controller is
how fast loaders worked. The 6502 in the drive basically compressed
the data to gain some speed over the serial bus, and the C=
decompressed it.
Since we are talking about using parallel and the cartridge port to
control this device... we've already killed a lot of compatibility.
Like it or not, 1541 compatibility means limiting communication to the
IEC port. The moment you patch the C64 Kernal you sacrifice 100%
compatibility.
This is basically a CMD-HD and RAMlink combined into a single unit.
It's using a FAT32 file structure as a root instead of a custom CMD
system, and D64 image as directories.
Without knowing more about the hardware, I don't know if there is
enough space in FPGA to support the multiple drive "driver" cores, but
they could easily be stored as drivers in a directory on the SD-Card,
and be loaded through the menu depending on the dot 3 suffix on the
disk image.
Load a D64, it loads a 1541 core into FPGA and makes the D64 the disk.
Pick D71, or D81, it loads those respective cores. Custom images with
slightly modified cores should also be possible to get the
functionality of 8MB and 16MB partitions.
Ideally I would love to write directly to the FAT32 File system for a
drive limited only by the size of the SD card. It would have no
compatibility with older systems, but sometimes you don't need that.
Wolfgang Moser
Pheuque schrieb:
> The only real difference from a 1571, or for that matter a 1581, as
> for as the controller is concerned is the number of tracks, and where
> the BAM/Directory info is stored.
not, if hardware emulation is done, is it?
> Since it's only reading from D64 files, there isn't any emulation of
> timing from read/write heads, or other more esoteric disk protection
> techniques.
This is not the way the 1541U does work, I
believe. Are mixing up something with other
devices like the MMC2IEC, MMC64, MMC Replay
or such?
> Like it or not, 1541 compatibility means limiting communication to the
> IEC port.
I really cannot follow you here. Most of
the old hardware floppy speeders always had
an "off" option to become 100% backwards
compatible in the most difficult cases.
> This is basically a CMD-HD and RAMlink combined into a single unit.
> It's using a FAT32 file structure as a root instead of a custom CMD
> system, and D64 image as directories.
The RAMLink does not have an original MOS
(Commodore) REU controller chip (REC), so
this is _not_ good for comparision.
> Without knowing more about the hardware, I don't know if there is
> enough space in FPGA to support the multiple drive "driver" cores, but
> they could easily be stored as drivers in a directory on the SD-Card,
> and be loaded through the menu depending on the dot 3 suffix on the
> disk image.
_If_ there is someone knowing how and willing
to do that. As such projects from the past do
show, there's mostly no co-programmer beside
the initial creator.
Womo
MagerValp
WM> What I would like to see would be parallel cable support in a way
WM> that the free VIA port within the emulated 1541 is connected to a
WM> dedicated VIA, CIA or PIA like port at the C64's expansion port.
DolphinDOS support would rule, and the changes to the FPGA would be
fairly small, but I'd wager that there aren't 8 free I/O lines...
MagerValp
P> Given that there is no REAL media, or drive mechanism, it's a matter
P> of reprogramming the controller what to expect.
Indeed.
P> Load a D64, it loads a 1541 core into FPGA and makes the D64 the disk.
P> Pick D71, or D81, it loads those respective cores.
Having actually written a 13.5 kB DOS for a computer that dynamically
reconfigures an FPGA (which, btw, requires two FPGAs, as you need to
be running somewhere while the other core reconfigures), I can tell
you that it's a hell of a lot more complicated than you think. Expect
a few months of work for something that is slightly buggy and not
feature complete.
If you want to use D71s and d81s, you're already using software that
doesn't require 100% 1541 compatibility - I suggest using IDE64,
64HDD, uIEC, IECATA, CMD drives, etc.
Wolfgang Moser
MagerValp schrieb:
>>>>>> "WM" == Wolfgang Moser <wn0...@d81.de.invalid> writes:
>
> WM> What I would like to see would be parallel cable support in a way
> WM> that the free VIA port within the emulated 1541 is connected to a
> WM> dedicated VIA, CIA or PIA like port at the C64's expansion port.
>
> DolphinDOS support would rule, and the changes to the FPGA would be
> fairly small, but I'd wager that there aren't 8 free I/O lines...
I more think onto my beloved super hardware speeder
Professional-DOS. Recreating the special GCR Codec
of Professional-DOS with VHDL would be snip with my
fingers. I did it with 3 16V8 GALs, so it shouldn't
be too difficult to adopt ???
As to the I/O lines required, we don't need them I
think, if the Dolphin-Kernal (C64) is patched to
expect a CIA like parallel port somwhere at
DExx/DFxx. Well, this would rule out other
non-virtual DD equipped drives on the bus.
Womo
PS: I really like dreaming about all the
possibilities of that thing. I really would make
it possible to create a super-super speeder that
actually does it's transfer via REU-like DMA from
the virtual floppy to the C64 _without_ losing 1541
emulation (albeit not 100% compatible anymore).
Pheuque
> If you want to use D71s and d81s, you're already using software that
> doesn't require 100% 1541 compatibility - I suggest using IDE64,
> 64HDD, uIEC, IECATA, CMD drives, etc.
But then I wouldn't be helping the development of this unit, which
means one less sale, which means less popularity, and overall failure.
I also wouldn't have it's REU features.
If I could find a source to buy, and get repaired, CMD equipment I
would do just that and call it a day.
What confuses me is that on one hand your claiming it must be 100%
1541 compatible, and the other supporting hacks like DolphinDOS that
equally kill true 1541 compatibility.
Since this isn't even close to being a shipping product, now is the
time to pass on any information of what *I* as a customer am looking
for.
Honestly, I would be happy to give up 71 and 81 compatibility, if
there was GEOS driver that allowed me to access files directly in the
FAT32 partition.
Wolfgang Moser
>> If you want to use D71s and d81s, you're already using software that
>> doesn't require 100% 1541 compatibility - I suggest using IDE64,
>> 64HDD, uIEC, IECATA, CMD drives, etc.
well, software that runs with a 1571 (in 71 mode)
and 1581 disk drives mostly don't need true 1571
or 1581 compatibilty. Such software mostly runs
from other drives as well, CMD's drive series for
example.
> But then I wouldn't be helping the development of this unit, which
> means one less sale,
Gideon hardly does make some profit from selling
these units.
> which means less popularity, and overall failure.
> I also wouldn't have it's REU features.
Leaving out true 1571 and 1581 emulation would
save a lot of bugs not don and therefore not to
fix.
> If I could find a source to buy, and get repaired, CMD equipment I
> would do just that and call it a day.
>
> What confuses me is that on one hand your claiming it must be 100%
> 1541 compatible, and the other supporting hacks like DolphinDOS that
> equally kill true 1541 compatibility.
Because Dolphin-DOS and other speeders are an
_option_. If they're disabled, the 1541 is truly
compatible again.
Please take in mind that even different 1541
models (VIC-1541, 1541 A-1, 1541 A-2, 1541B,
1541-II) are not 100,00000000% compatible to each
other. Therefore an emulation nevr can reach _the_
perfect 1541 emulation, but only perfect emulation
of _one_ model.
> Since this isn't even close to being a shipping product, now is the
> time to pass on any information of what *I* as a customer am looking
> for.
Somewhere I read that Gideon plans to release
the whole project as Open Source when it is
finished (from his point of view).
So, in the end, there will not be any customers
since he does not create a business from this
device, does he?
> Honestly, I would be happy to give up 71 and 81 compatibility, if
> there was GEOS driver that allowed me to access files directly in the
> FAT32 partition.
Get up your compiler/assembler and give it a try
;-)
Womo
MagerValp
P> What confuses me is that on one hand your claiming it must be 100%
P> 1541 compatible, and the other supporting hacks like DolphinDOS
P> that equally kill true 1541 compatibility.
Only it doesn't. Like JiffyDOS it's fairly transparent and only a
handful of games fail with it enabled. D71/D81/FAT32 access would
require far reaching and compatibility killing changes, while
DolphinDOS would just require exposing the internal parallel port
(like a real 1541), adding ram (like a real 1541), and changing the
drive rom (like a real 1541).
P> Honestly, I would be happy to give up 71 and 81 compatibility, if
P> there was GEOS driver that allowed me to access files directly in
P> the FAT32 partition.
I wouldn't hold my breath, but only Gideon can give a final answer.
Nicolas Welte
> I knew about it for some days now, but Gideon now announced it
> officially: The 1541 Ultimate will also be available with a 32MB SDRAM
> chip that is used to emulate a Commodore REU with 16MB RAM!
>
> The features of the cartridge are very impressive:
> - 512kB SRAM
> - 4MB Flash Rom
> - 32MB SDRAM (only on the Ultimate Plus)
> - SD card Interface
> - AR and FC3 cartridge emulation
> - file browser to select disk images and DMA-load PRGs
> - fully compatible 1541 emulation
> - fully compatible REU emulation with up to 16MB (only Ultimate Plus)
> - file browser also works in C128 mode for disk image selection!
spec update:
Gideon informed, that the production version will offer only 2MB of Flash
ROM. With configuration Data and ROM images being loadable from SD card as
well, there's no reason to have such a big Flash ROM and no disadvantages
should result for the user.
Also everybody who placed a preorder should have gotten a confirmation mail
from him by now.
Nicolas
hg
"Nicolas Welte" <welte...@freenet.de> wrote in message news:5u12haF...@mid.individual.net...
> Nicolas Welte wrote:
snip
> spec update:
> Gideon informed, that the production version will offer only 2MB of Flash ROM. With configuration Data and ROM images being
> loadable from SD card as well, there's no reason to have such a big Flash ROM and no disadvantages should result for the user.
>
> Also everybody who placed a preorder should have gotten a confirmation mail from him by now.
>
> Nicolas
What type of additional features as Gideon says in his email could be added in the future to 1541U Plus? I don't know if I should
buy the normal version or plus version. Tough decision when Gideon says extra features will be added but without knowing what he's
got planned it seems like a waste to get the plus version. Then again it's only euro 20 more so it is tempting.
Anyone got any idea what the extra ram could be used for (apart from REU)? I would definitely buy the plus version if it had a
bigger FPGA with lots of extra capacity as i'm sure there could be several fascinating add-ons implemented with that but extra ram
doesn't really seem that exciting to me.
Wolfgang Moser
please note that, albeit answering to your question, I'm in no tight
contact to Gideon (yet) and so don't nothing about his plans. It's all
about reading his website, some beta tester's notes and doing some
conclusions.
hg schrieb:
> "Nicolas Welte" <welte...@freenet.de> wrote in message news:5u12haF...@mid.individual.net...
>> Nicolas Welte wrote:
> snip
>> spec update:
>> Gideon informed, that the production version will offer only 2MB of Flash ROM. With configuration Data and ROM images being
>> loadable from SD card as well, there's no reason to have such a big Flash ROM and no disadvantages should result for the user.
>>
>> Also everybody who placed a preorder should have gotten a confirmation mail from him by now.
>>
>> Nicolas
>
>
> What type of additional features as Gideon says in his email could be added in the future to 1541U Plus? I don't know if I should
In my opinion, Gideon itself does not know what to add next. With the
Plus version there're just only 16MB used from the available 32MB SDRAM
for REU emulation. I expect that not all of the macrocells of the FPGA
chip are used for some sort of logic. So, 16MB of unused RAM plus some
left over FPGA macrocells let enough room to do something additional.
> buy the normal version or plus version. Tough decision when Gideon says extra features will be added but without knowing what he's
> got planned it seems like a waste to get the plus version. Then again it's only euro 20 more so it is tempting.
> Anyone got any idea what the extra ram could be used for (apart from REU)?
Hmmmm, looking onto the DTV, something like a "Super-DMA chip" come to
my mind, something that could be told an extension of the REU controller
chip (REC), giving access to the whole 32MB for one. And extenting the
REC, so that it becomes able to do the Blitter things known from the
DTV. With such memory-to-memory (C64-to-C64) transfers, some wonderful
screen routines are thinkable.
> I would definitely buy the plus version if it had a
> bigger FPGA with lots of extra capacity as i'm sure there could be several fascinating add-ons implemented with that but extra ram
> doesn't really seem that exciting to me.
Different FPGA sizes between the Basic and the Plus version are not very
likely; although this is only an assumption. You would need to quality
test two different designs each time you deliver updated cores.
Diversity can be a real resource killer for such a hobbyists project.
I personally had absolutely no difficulties to get my decision made:
I appreciate the integrated REU emulation very, very much, so it was not
question to choose the Plus version.
Womo
hg
cartridge back in the 80's.
hg
>I guess i'll be more than happy with the standard version. You know, i would have killed someone (MI5 Guy?) for a 1541Ultimate
>cartridge back in the 80's.
Just in case someone from MI5 is actually reading this post, the above statement is a complete and utter 100% joke meant to show how
much I would like to own a 1541U cart :-)
retroc...@aol.com
GEOS users, who's going to benefit when no one likes developing
software above 1Mhz/64k?
Regards,
Shaun.
christianlott1
that's where the flash mode comes in handy. you develop your ap within
the standard 64k limit but you can switch between as many 64k aps as
desired.
i don't think it's a call to develop 16mb aps. it simply seems to be a
smart way to save and restore your place (game/ap or whatever...
(i guess. i've never owned an reu)
Sam Gillett
"hg" wrote ...
I don't think MI5 monitors this newsgroup. But, don't relax yet. A CIA
spook reads this group because he had a C64 when he was a kid. ;-)
--
Best regards,
Sam Gillett
Why is the third hand on a watch
called the second hand?
Brian Ketterling
hg <h...@hg.hg> wrote:
> Just in case someone from MI5 is actually reading this post, the above
> statement is a complete and utter 100% joke meant to show how much I
> would like to own a 1541U cart :-)
I doubt they actually get down to reading very many messages, but I wouldn't
be surprised if they monitor Usenet, etc., for key words and phrases... in
which case /MI5/ is probably begging Google to cut that guy off!
Brian
--
Pheuque
even BOTHER to investigate when Spammers were murdered. As it SHOULD
be.
On Jan 3, 4:34 pm, "Brian Ketterling" <tweel6...@no-potted-meat-
products-peoplepc.com> wrote:
> Innews:LICdndXTe_2...@pipex.net,
Dombo
> On Dec 31 2007, 7:19 pm, MagerValp <MagerV...@cling.gu.se> wrote:
>
>> If you want to use D71s and d81s, you're already using software that
>> doesn't require 100% 1541 compatibility - I suggest using IDE64,
>> 64HDD, uIEC, IECATA, CMD drives, etc.
>
> But then I wouldn't be helping the development of this unit, which
> means one less sale, which means less popularity, and overall failure.
I think you overestimate your own importance.
Anssi Saari
>>>>>> "c" == christianlott1 <christi...@yahoo.com> writes:
>
> c> i'd like to know that G64 images work before i order something like
> c> this.
>
> Why? Is there anything out there that doesn't run from plain d64s?
I know of one, Portal. There are cracked D64s on Arnold, but they work
for disk #1 only. I've had some correspondence about this with "Mason
C64heaven" and he actually sent me some images to test, but they
didn't seem to be an improvement.
MagerValp
CL> i'd like to know that G64 images work before i order something
CL> like this.
MV> Why? Is there anything out there that doesn't run from plain d64s?
AS> I know of one, Portal. There are cracked D64s on Arnold, but they
AS> work for disk #1 only. I've had some correspondence about this
AS> with "Mason C64heaven" and he actually sent me some images to
AS> test, but they didn't seem to be an improvement.
As I said in another reply, a bad crack is hardly a showstopper.
Sounds like someone needs to do a proper crack instead :)
Pheuque
Like you did when you decided to respond.
Seriously, if people like me don't adopt this, and pay for it
development, WHO WILL.
I'm willing to spends $250 USD on this IF it does what I want.
While putting the occasional D64 image into a virtual drive and
playing some ancient game might be cool... it's not $250 cool to me.
From what I've read, this thing can be made to do what I want, and I'm
sure I'm not alone is wanting access to larger than the 1541's 160K on
my 4GB SDCARD.
With the number of active C= users probably in the low thousands world
wide, I would think EVERY one of their opinions about new hardware is
important.
Even yours.
As to your opinion of me... sound out my name.
Pete Rittwage
>>>>>> "AS" == Anssi Saari <a...@sci.fi> writes:
>
> CL> i'd like to know that G64 images work before i order something
> CL> like this.
>
> MV> Why? Is there anything out there that doesn't run from plain d64s?
>
> AS> I know of one, Portal. There are cracked D64s on Arnold, but they
> AS> work for disk #1 only. I've had some correspondence about this
> AS> with "Mason C64heaven" and he actually sent me some images to
> AS> test, but they didn't seem to be an improvement.
>
> As I said in another reply, a bad crack is hardly a showstopper.
> Sounds like someone needs to do a proper crack instead :)
>
Portal disk sides 2,3,4,5 all have data stored and referenced in the
game itself, so there is no CBM-DOS, BAM or filenames or anything like
that. It loads the sectors from it's own internal table using it's own
method. You'd have to reprogram the internal loader routine from
scratch to fix this, including how it identifies each of the 4 disks.
--
-
Pete Rittwage
http://rittwage.com
C64 Preservation Project
http://c64preservation.com
christianlott1
> MagerValp wrote:
> >>>>>> "AS" == Anssi Saari <a...@sci.fi> writes:
>
> > CL> i'd like to know that G64 images work before i order something
> > CL> like this.
>
> > MV> Why? Is there anything out there that doesn't run from plain d64s?
>
> > AS> I know of one, Portal.
is this a good game or something?
Golan Klinger
> is this a good game or something?
Portal isn't really game. Think of it more as interactive fiction and as
far as that goes, it's quite good.
--
Golan Klinger
Dark is the suede that mows like a harvest.
MagerValp
MV> As I said in another reply, a bad crack is hardly a showstopper.
MV> Sounds like someone needs to do a proper crack instead :)
PR> Portal disk sides 2,3,4,5 all have data stored and referenced in
PR> the game itself, so there is no CBM-DOS, BAM or filenames or
PR> anything like that. It loads the sectors from it's own internal
PR> table using it's own method. You'd have to reprogram the internal
PR> loader routine from scratch to fix this, including how it
PR> identifies each of the 4 disks.
Sounds like your average trackloading game :) If there's a central
file table, extracting all the data from the disks is easy. Loaders
with file references scattered throughout the code on the other hand
are a PITA...
MagerValp
P> Seriously, if people like me don't adopt this, and pay for it
P> development, WHO WILL.
Actually a whole bunch of people. In Gideon's own words:
"The demand for this unit has proven to be so much larger than I
anticipated, that I have been working hard the last days on having
the unit ready for mass-production."
hg
people who still use real C64 hardware.
The software I load up on my C64 is mainly 80's game software, PD demos mainly from the 90's to the present day, and listening to
SID music right from the beginning all the way to the very latest 2008 compositions.
The game software I load up and mess around with is almost 90% a nostalgia thing for me wanting to remember the happy days. Every
now and again I try to have a crack at completing the ever decreasing number of my favourite games that I never finished (Frankie
goes to Hol was the last one I finished - it's ending certainly was different). In fact every piece of 80's software is a nostalgia
thing for me. With the demos I marvel at the power the demo coders squeeze out of a 1mhz system and the SID tunes I listen to
because only a real SID can recreate that 80's nostalgia thing for me and the newer compositions were almost certainly meant to be
played on a real SID not an imperfect emulation.
To me, all these programs can only be appreciated *fully* on a real C64 on the hardware they were designed for. The 80's nostalgia
feeling is gone (or at least spoiled) when I use emulation and like I said before demos and SIDs are meant to be viewed and listened
to on real hardware. IMO the purpose and objective of these programs is to be run on real hardware. Task completed in my view.
When people use non-entertainment software on a real C64 I often wonder why go to all the trouble? I would think the objective of
using non-entertainment software is to achieve a task which could be completed hundreds of times more efficiently on a newer system
or at the very least in an emulated 64. The objective of non-entertainment software is to achieve a task which in my view doesn't
require real hardware for the objective to be completed.
Of course I'm not telling anyone what to do and whoever is using non-entertainment software on their 64's more power to them but it
does strike me as being a rather odd thing to do. But then I'm in the C64 camp that thinks computers should be fun.
Especially 80's computers.
christianlott1
> >>>>> "PR" == Pete Rittwage <rc...@rittwage.com> writes:
> PR> Portal disk sides 2,3,4,5 all have data stored and referenced in
> PR> the game itself, so there is no CBM-DOS, BAM or filenames or
> PR> anything like that. It loads the sectors from it's own internal
> PR> table using it's own method. You'd have to reprogram the internal
> PR> loader routine from scratch to fix this, including how it
> PR> identifies each of the 4 disks.
>
> Sounds like your average trackloading game :) If there's a central
> file table, extracting all the data from the disks is easy. Loaders
> with file references scattered throughout the code on the other hand
> are a PITA...
If you do this I sure hope you put up docs about your adventure like:
http://banguibob.gigacities.net/
MagerValp
MV> Sounds like your average trackloading game :) If there's a central
MV> file table, extracting all the data from the disks is easy.
MV> Loaders with file references scattered throughout the code on the
MV> other hand are a PITA...
CL> If you do this I sure hope you put up docs about your adventure
CL> like: http://banguibob.gigacities.net/
His RapidLok dissection is lots of fun to read, but I'm short on spare
time so I'm only halfway through. I'm (ever so slowly) working on
cleaning up my Ultima project sources so that they can be released.
There won't be a friendly article explaining everything, but the
sources should hopefully be useful if someone else wants to crack
another large, multi disk game.
Nicolas Welte
Pete Rittwage wrote:
> Portal disk sides 2,3,4,5 all have data stored and referenced in the
> game itself, so there is no CBM-DOS, BAM or filenames or anything like
> that. It loads the sectors from it's own internal table using it's own
> method. You'd have to reprogram the internal loader routine from
> scratch to fix this, including how it identifies each of the 4 disks.
So far, this sounds like Maniac Mansion Side 2 or Zak McKracken, both sides
of the game disk. Data is stored in all sectors, including track 18, so
there is no BAM and directory or CBM DOS. Still both games work fine from a
D64. BUT they use the standard CBM sector format. Is this different in Portal?
Nicolas
--
www.x1541.de
Anssi Saari
> As I said in another reply, a bad crack is hardly a showstopper.
> Sounds like someone needs to do a proper crack instead :)
Yes! Someone might even be able to squeeze the whole thing on one
disk, since there has to be lots of redundancy on the five disks...
Pete Rittwage
It is stored in CBM format, but the loader is searching for sectors by
looking at the GCR headers directly, rather than using the kernal
routines. Since the D64 doesn't contain this info, it fails.
Nicolas Welte
> Nicolas Welte wrote:
>> So far, this sounds like Maniac Mansion Side 2 or Zak McKracken, both
>> sides of the game disk. Data is stored in all sectors, including track
>> 18, so there is no BAM and directory or CBM DOS. Still both games work
>> fine from a D64. BUT they use the standard CBM sector format. Is this
>> different in Portal?
>>
>> Nicolas
>>
>
> It is stored in CBM format, but the loader is searching for sectors by
> looking at the GCR headers directly, rather than using the kernal
> routines. Since the D64 doesn't contain this info, it fails.
Ok, in this case it should run fine on the 1541 Ultimate, since it converts
the D64 into GCR data internally, and the emulated 1541 works on this
internal GCR image of a disk. I think this is similar to how VICE works?
Nicolas
--
www.x1541.de
Snogpitch
circa 1997?
That collection included some games for Atari 2600 and Commodore 64. Volume
3 includes a total of 57 games of which 15 are Commodore, and one of those
is Portal. And it was designed to work on a Windows 95 system.
http://www.cdaccess.com/html/pc/vault3.htm
Seems to me they figured out how to do it already with emulators 10 years
ago.
in article 477FCFDB...@rittwage.com, Pete Rittwage at
rc...@rittwage.com wrote on 1/5/08 1:43 PM:
Golan Klinger
> Has anyone looked at how it was done on the Activision Game Vault series
> circa 1997?
Yep. See this discussion:
http://www.lemon64.com/forum/viewtopic.php?t=19270
christianlott1
> >>>>> "P" == Pheuque <Ratte...@gmail.com> writes:
>
> P> Seriously, if people like me don't adopt this, and pay for it
> P> development, WHO WILL.
>
> Actually a whole bunch of people. In Gideon's own words:
>
> "The demand for this unit has proven to be so much larger than I
> anticipated, that I have been working hard the last days on having
> the unit ready for mass-production."
This is a big red flag. Gideon admits he's under anticipated such a
large production.
As exemplified in these (2) threads, there are many things users would
like to do with this that are still unknowns. Stalling production a
few months would allow him to respond to some of these questions
accurately and give some feedback without having committed in hardware
something which lacks such and such a feature that could have been
conveniently handled before money spent.
This piece of hardware appears indispensable. The price seems set at US
$275. With a large enough production run I hope he might make a little
money.
As soon as he says G64/41 is 100% it's a done deal for me though ;)
Cameron Kaiser
>>is this a good game or something?
>Portal isn't really game. Think of it more as interactive fiction and as
>far as that goes, it's quite good.
I actually have the book as well (signed by Rob Swigart). The book fills
in a few gaps that the game does not.
That said, the Activision 15-Pack did run it fully off .d64s. However, I
believe they patched that version to eliminate the ID check, so it should
be possible to do the same outside of the 15-Pack's custom emulator.
--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.cameronkaiser.com/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
Cameron Kaiser
>>Has anyone looked at how it was done on the Activision Game Vault series
>>circa 1997?
>Yep. See this discussion:
>http://www.lemon64.com/forum/viewtopic.php?t=19270
Ah well. In that case, it sounds like the emulator was patched around it
instead.
Golan Klinger
> I actually have the book as well (signed by Rob Swigart). The book fills
> in a few gaps that the game does not.
I have it too although mine isn't autographed. It's worth checking out and
it is still in print so getting it isn't difficult. There's also this:
I have the feeling we've discussed this before. You?
> That said, the Activision 15-Pack did run it fully off .d64s. However, I
> believe they patched that version to eliminate the ID check, so it should
> be possible to do the same outside of the 15-Pack's custom emulator.
For the record, the disk images from the Activision 15-Pack do not work with
Power64 or VICE.
MagerValp
c> This is a big red flag. Gideon admits he's under anticipated such a
c> large production.
Er... no. It means that the product he's offering, with the current
feature set (later G64 support would be a bonus), is exactly what
people have been waiting for.
c> As exemplified in these (2) threads, there are many things users
c> would like to do with this that are still unknowns.
What unknowns? We're getting a device that lets us use d64s with demos
and cracked games, which covers 99% of what people do with 1541s
today.
c> The price seems set at US $275.
EUR 119, for the REU version, is $175. The REU-less version is EUR 99,
or $145.
christianlott1
> >>>>> "c" == christianlott1 <christianlo...@yahoo.com> writes:
>
> c> This is a big red flag. Gideon admits he's under anticipated such a
> c> large production.
>
> Er... no. It means that the product he's offering, with the current
> feature set (later G64 support would be a bonus), is exactly what
> people have been waiting for.
says you and those willing to buy now. what about those who'd rather
wait for g64? what about OUR feeling? don't we count? ;((
> c> As exemplified in these (2) threads, there are many things users
> c> would like to do with this that are still unknowns.
>
> What unknowns?
G64, Dolphin DOS, Professional DOS, D71/81, etc..
> We're getting a device that lets us use d64s with demos
> and cracked games, which covers 99% of what people do with 1541s
> today.
There should be a poll then. I really think he could get a greater buy
in (more sales) if more features were absolutely known and
implemented.
> c> The price seems set at US $275.
>
> EUR 119, for the REU version, is $175. The REU-less version is EUR 99,
> or $145.
oops. that was a typo..
sorry!
I'm not trying to be a nay sayer. I'm excited about this!
Wolfgang Moser
please take into your mind that Gideon is a
one man artist. He does not own a big company
with a whole group of developers to fulfill
everybody's wishes.
He did this all in his spare time and asks us
to pay only for the parts costs and the PCB.
Maybe soldering also, if the "mass" of the
production run is big enough.
There simply must be a cut made or the device
would never get out of development and its
price would rise and rise for every additional
feature... Well, I know what I'm talking off
since I'm developing a clone of some old
hardware for 4.5 years now. I'm still not
satisfied with the current implemeted features
and the remaining bugs, so I will have to
fiddle around with it some more years. And no
one beside some beta testers and myself are
able to have fun with that device :-( That's
nothing else than the worst case, hours over
hours invested into development and then what
for?
Please, be patient, wait until the current run
of people having ordered the 1541U are able to
do some testing and then start reporting over
it here and on other places. Maybe some new
features have already been implemented, when
the final production device is shipped.
_Then_ you may decide to buy such a unit
yourself -- well, if Gideon takes another
production run.
It is as it currently is, take it or leave out,
what else can be said?
Womo
hg
alone. I can't remember the name of the guy from Australia who was working on his own FPGA 1541. IIRC he was doing some work with
G64's so maybe he can collaborate with Gideon on some further updates to this cart if he has the desire to. Anyway, with the project
open source there'll always be someone making slight improvements to this cart so it looks like the future is rosy for 1541Ultimate.
christianlott1
> _Then_ you may decide to buy such a unit
> yourself -- well, if Gideon takes another
> production run.
:)
which is the reason I'm stressing. those who decide to wait may be
waiting indefinitely for something they would have purchased if they
knew it worked.
i'm beginning to think the best thing would be to buy now and hope
instead of 'wait and see'. if the 1541u turns out to be able to do
what i want a few months down the road and there's no new production
run i'll wind up seeing the 1541u on ebay for $1,000 buy it now!
worst case is that he makes 100 of them, then changes hw to support
new features, then does another run a year from now and the 100 who
bought in early will be wondering if another $175 ($350 total) is
worth it.
i really don't see what the rush to production is. he's his own boss.
maybe he really is sure the hw part is complete and will not need a
revision and that the features we've mentioned are either sw issues or
impossible.
btw, when's the cut off date for pre-order?
Wolfgang Moser
christianlott1 schrieb:
> Hello Womo,
>
>> _Then_ you may decide to buy such a unit
>> yourself -- well, if Gideon takes another
>> production run.
>
> :)
>
> which is the reason I'm stressing.
I can fully understand your situation. On one side
you may only want to pay for a product that is readily
available on a this-for-that basis. But here you have
to become some sort of investor instead of a native
customer... I got the very same doubts, believe me.
> those who decide to wait may be
> waiting indefinitely for something they would have purchased if they
> knew it worked.
That's true, Nicolas Welte surely can tell stories
about a hobbyist's way of life, who creates devices
that end up in a "greater hell of demand".
I really don't know how Gideon may feel, after he got
the job for the first production run done. He _may_
feel very tired then. But he also may get another run,
when more people like you are asking for the "field
tested" version.
> i'm beginning to think the best thing would be to buy now and hope
> instead of 'wait and see'. if the 1541u turns out to be able to do
> what i want a few months down the road and there's no new production
> run i'll wind up seeing the 1541u on ebay for $1,000 buy it now!
Yeah, _that_ will be my one (that's a joke, sorry ;-)
Well, _I_ decided to buy it now with absolutely having
taken into my mind that there _is_ the risk to lose my
money. It's the very same as with any other sort of
investment, there're always risks to consider.
> worst case is that he makes 100 of them, then changes hw to support
> new features, then does another run a year from now and the 100 who
> bought in early will be wondering if another $175 ($350 total) is
> worth it.
>
> i really don't see what the rush to production is. he's his own boss.
> maybe he really is sure the hw part is complete and will not need a
> revision and that the features we've mentioned are either sw issues or
> impossible.
As I said above, I can fully understand you, the
current situation is a bit difficult. For me that
device most probably will become pure fun, even if
all the features I'm dreaming of cannot be realized
with it in the end.
> btw, when's the cut off date for pre-order?
I didn't ask, but from some comments in the german
Forum-64 Gideon only wanted to wait one week for the
people to do their payments.
Since there seem to be some people short on money
currently he _may_ wait another week or so, I really
don't know.
Womo