Ja, so was für den MEGA65 wäre super. Ich personlich habe nicht genug Zeit, so eine Seite herzustellen, während ich auf der Fertigung der Maschine arbeite. Aber wenn jemandem es versuchen möchte, wäre es bestimmt ein Geschenck für die Community.
LG
Paul.
It probably wouldn't be that huge a job to adjust the number of sectors per track + expand the BAM, which is the only material change required. That may, or may not, make it FD2000 compatible.
One of my furutre projects I would like to do, is to see just how much data can be crammed on a 1,44MB disk using modern error correction schemes, and continuously variable data rate variation on each track. I suspect more than 2MB is possible.
Paul
Hello,
it is likely that we could have the DevKits for sale, before the tools for the injection moulding are even built -- as that process can take upto around 6 months.
LG
Paul.
Hallo Leute,
at the moment, using HD or ED disks and drives is not supported, but the changes required are only in VHDL and software. The vast majority of the logic is already in our floppy controller for this. It's just not a priority for us to finish right now. This is one of the many fun things that we will all be able to work on post-release 
In fact, the floppy controller can be easily modified to read 1541 disks, and maybe even the stranger ones like the SFD1001 with a 5.25" drive.
The reason for having only micro-SD card on the back, is to avoid having to make the PCB any wider, as the rear side is already covered in ports. Our compromise to this was to include a 2nd SD card adapter accessible from the trap-door. But also as we keep saying, the 100mbit ethernet means you can copy data onto and off of the SD card super fast. We have already written most of a TFTP server for the MEGA65, so that you can copy files from existing computers nice and easily. It reads from the SD card at >500KB/sec, so faster than you can fiddle with an SD card. We'll likely also make tools for downloading files from the internet onto the SD card etc, once we have the machine released.
LG
Paul.
Grüße aus dem Outback,
ok, so to answer a few of the questions raised above:
1. The PMOD expansion connectors can be made to support quite a variety of expansion boards, including potentially at the same time. It really boils down to bandwidth and latency requirements. The tape port is super easy here: 10usec latency and only one real signal with a maximum bandwidth of something like 100khz. The user port requires somewhat more, with some signals requiring sensitivity at around 16MHz, and might require a dedicated pin or two on the PMOD to achieve this. But the rest of the pins can likely be accommodated using four wires on a PMOD, with signalling frequency of something like 8 - 16 MHz. So overall, I am not really worried about this: It should be possible to make a number of expansions all work together at the same time.
2. Making the case injection mouling tools takes a long time, especially if you want the tools to actually work 
My feeling is that it will be summer before we have the case mould tools, and the first pieces made using them.
3. We are realistically working on the basis of manufacture batches of, at this stage of thinking, of around 250 units. The pricing will be based on that level of purchasing power for components. As usual, we won't be speculating on the final price, until we know the cost to us of the major components.
LG
Paul.
adtbm - Is it possible to get listed in the manual with a real name? I donated using the forum/GitHub pseudonym..
[edit]
We’ve been listening to you and we will implement additional port slots you’ve been asking for, in the MEGA65 case for additional ports (i.e. User-Port, Tape-Port)! This makes the MEGA65 look closer to the original c65 look and more versatile for each individual retro computing fan!
Will it be possible to have both at the same time? In my opinion it would be the best to have all the back side covered with port slots, even if you don't have any idea what could be placed there - you can't know what daughter-boards might get created in the future.
This is the idea. We were only talking about it last night, that having both a userport and tape port shaped hole gives maximum flexibility for everyone, whether they want to have a real tape drive connected at some point (like me ;), or use it for some evil USB expansion or something (unlike me ;).
But of course in all this, I just want to add my note of appreciation to everyone who has contributed financially and otherwise so far -- it takes a village to raise a child, and the same goes for resurrecting an old computer We wouldn't have got so far without the help of you all.
LG
Paul.
It's the version that we use, for lack of a later one. There is rumoured to be one that is a bit newer.
LG
Paul.
Hmmm... I am sure I have actually used it with a , on the 91101 ROM, but will have to check. The difference is whether BASIC prints the ? for you or not, is my recollection.
Just confirmed on real hardware with that ROM. With , it indeed works, just without a ? prompt.
LG
Paul.
Sounds good.
DMAgic ignores MAP status by design.
LG
Paul.
It's hard to know, for sure. It might just have been the cheapest option in terms of silicon, an they figured that a pile of stack operations to conserve/restore registers was not too bad. In practice, CBM used absolute store/loads to save regs when context switching between KERNAL and DOS on the C65, which added a latency or probably 100 clock cycles, and which contributtes to slow load/save times on the C65's internal drive.
LG
Paul
Well, if you test it on real hardware and it works, then it will be much easier than using MAP. MAP is the most horrible thing for almost every use-case: You lose all register contents, can't tell where you currently are etc.
LG
Paul.
Display MoreEs gibt ja auch noch die Option es wie beim Ultimate64 zu machen.
Das der User die benötigten ROMS selber besorgen muss
und sie vor der ersten Benutzung erstmal selber "flashen" muss.
Diese werden dann vom MEGA65 geprüft
und gepatcht so das der Rechner erst dann wirklich funktioniert.Hej Paul ist das nicht auch eine Option?
In principle this could be done, but (a) no patching of original ROMs is required; and (b) we really want the MEGA65 to be able to boot up first time, without having to mess about with finding and installing ROMs.
LG
Paul.
Meinerseits würde ich mit dem MEGA65 Grafiks Modii und Routinen hilfe anbeten, wenn es alles einfacher mächte.
LG
Paul.
Looking at the layout of the Vampire V4 here:
https://wiki.apollo-accelerato…/pcb_v4_up_details_r9.jpg
It would need a fairly serious adapter board, or could "simply"* be rearranged. The board itself is only about 12x10cm, so overall space is not the problem.
LG
Paul
* I totally get how much of a pain and how time consuming it can be to lay out PCBs. But its still easier than messing with injection moulding tools.
From memory it needs to be first enabled via the Hypvervisor. I also don't recall off the top of my head if they are completely working.
Taking a look at the VHDL:
0. Enable with bit 2 of $D67D from inside Hypervisor.
1. It should be CLD / CLD / <JMP|JSR|RTS> to do the 32-bit addressed actions.
2. There might be a funny thing where you have to subtract $4000 from the 32-bit address for these operations, because they work internally using MAP-style mapping, which will add $4000 to the address at run-time.
But I don't know if I ever actually tested it.
Almost certainly not implemented in Xemu.
LG
Paul
Display Morees geht hier nicht um pro / contra vampire.
sondern darum ein größeres publikum anzusprechen, die interesse hätten
an einem neuen tastaturgehäuse, die gerne eine vampire hätten.
wenn die modifikationen nicht allzu groß wären, hätte man darüber
nachdenken können.
aber wenn es nicht machbar ist, dann ist das so, und der thread kann auch zu.
Let me give a slightly more posiitive outlook here: The sensible approach in my view, would be to make an adaptor board for the Vampire that allows it to fit in an unmodified MEGA65 case. This would be a much cheaper and easier approach. Alternatively people could buy and hack up MEGA65 cases to fit their Vampire boards.
Meanwhile, this also overlooks the situation that it is very likely possible to implement a decent Amiga core in the MEGA65's own FPGA, and switch to it when you want, e.g., with GO 500 from BASIC.
LG
Paul.
Definitely not a waste of time.
1. If the C65 ROM gets open sourced tomorrow, we have several routines we can transplant to improve the original ROMs.
2. This project is not just for Mega65. I really want to have a Kernal for my Ultimate 64 which can talk both JiffyDOS and DolphinDOS without ROM switching, for now ours is the only one capable of doing so. Main problem is the compatibility, which is not too good as of yet.
3. I'm having fun working on it.Also don't forget that the OpenROMs solve the legal uncertainty for emulators to include a working ROM set.
It all depends on the rate of compability.
Besides the own "fun working on it" it could be frustrating, if some people works much on a OpenROM and then 99% of all Mega65 buyers uses the original ROMs because of 100% compabitily. So all the work for the OpenROMs was just for "own fun".
To be clear here: I am talking primarily about having ROMs for emulators to distribute, not the MEGA65.
Of course most people might want to use the genuine ROMs.
That is what I'm trying to say.
I understand the OpenROM affords from your seller point of view. To ship the Mega65 with at least some ROM in a legal way.
... but, yes, if we have no other option, we will at least have SOMETHING to distribute with the MEGA65. This avoids a major potential risk for us, even if people decide for themselves to put original C65 ROMs in the moment they get the machine. The main point is that the machine is at least usable in some way immediately on receiving it.
Compatibility with specific games is actually usually fairly easy to fix, so if we were forced to do it this way (and I don't think that we will be), then we can easily qualify a list of a few hundred games, if required, by testing them and fixing any incompatibilities. Lots of games actually work just fine with the OpenROMs already, last I checked.
LG
Paul.
Why should someone use a OpenROM with less compability if the original 100% ROM is "just one click away"?
Why does someone use Linux although his computer was delivered with Windows?
Because it lets the emulators ship able to run at least some software, and show a nice friendly READY prompt, instead of requiring the user to do some complicated things first. It gives a legally certain fall back position. Of course most people might want to use the genuine ROMs. That's fine. But for those users for whom it is too complicated, will still have something to use.
LG
Paul.
Definitely not a waste of time.
1. If the C65 ROM gets open sourced tomorrow, we have several routines we can transplant to improve the original ROMs.
2. This project is not just for Mega65. I really want to have a Kernal for my Ultimate 64 which can talk both JiffyDOS and DolphinDOS without ROM switching, for now ours is the only one capable of doing so. Main problem is the compatibility, which is not too good as of yet.
3. I'm having fun working on it.
Also don't forget that the OpenROMs solve the legal uncertainty for emulators to include a working ROM set.
LG
Paul
1. Ist das BASIC 10 in seiner Definition und Beschreibung (Syntax, Semantik) vollständig, sodass man genau weiß, was noch gemacht werden müsste?
2. Ist im ROM überhaupt noch genug Platz dafür?
3. Gibt es in BASIC 10 echte Integer-Variablen?
4. Gibt es einen BASIC-7-Compiler, den man nur noch umschreiben bräuchte?
1. Ungefähr so. Mindestens haben wir einen Dokument, das alles beschreibt wie wir es erwarten. Siehe hier unter "Documentation": https://mega.scryptos.com/sharefolder/MEGA/MEGA65+filehost
2. Kein Ahnung Es wird uns wirklich freuen, wenn irgendjemand daran arbeitet, einen Patch File für C65 ROM schafft, der einige dieser fehlender Dinge rechtfertigt. Der MEGA65 hat noch 128KB mehr Speicher als C65. Deshalb wenn alles nicht im ROM passt, soll es kein großes Problem sein.
3. Ich glaube, genauso weit (oder unweit) wie im BASIC 7.
4. Nicht dass ich kenne. Aber irgendjemandem darf natürlich so einen schaffen. Wäre natürlich Super. Einfach ein BASIC 7 nach 10 Umwandler wäre genug. Noch besser, wenn er auf dem MEGA65 selber laufen könnte und ein BASIC 7 Programme einlesen, umwandeln und wieder aufs Diskette schreiben lassen.
Hallo Paul,
das habe ich mir schon gedacht. Es ist nur der Basic10 Befehl Collision, der nicht funktioniert. Daher möchte ich ja auch wissen, welche Speicherstelle für bei einer Spritekollision gesetzt wird. Ist es dieselbe, wie beim VIC-II ($D01E)?
Ja, so muss es natürlich sein, sonst C64 Spiele könnte nicht richtig funktionieren. Der VIC-IV ist abwärts mit dem VIC-III und VIC-II kompatibel. Dies ist schon teilweiser im "MEGA65 Book" beschrieben. Link oben.
Der Mega65 macht wirklich echt Spass. Das ein Emulator wie XEmu nicht den Spass bringt, ist eigentlich auch klar. Auf einer richtigen Maschine bringt schon das Programmieren richtig fun. Das Projekt ist noch nicht abgeschlossen, so dass man damit rechnen muss, das noch nicht alles funktioniert. Es wäre aber schön, wenn mehr Leute sich für seine Realisierung einsetzen würden. Es sind nur eine Hand voll Leute, die an dem Projekt hauptsächlich arbeiten und das in ihrer Freizeit machen. Die Ergebnisse lassen sich daher echt sehen.
Ob das Gerät etwas für einen ist oder nicht, ist wohl Geschmacksache. Ich denke, das es für dieses Gerät einen Markt gibt, z.B. Demoprogrammierer. Jemand, der nur entspannt zocken will, wird wohl eher zu einem normalen C64 greifen oder zum Ultimate64.
Hier kann ich einfach nur sagen: Je mehr Hände an der Arbeit es gibt, desto schneller die Maschine raus kommt! Wir machen es, groß Teils nur weil es so viel Spaß leistet, an dieser Maschine zu arbeiten. Wir laden euch alle ein, in dem Spaß mitzuteilen
LG
Paul.
