Hi Niclas!

On Tue, 2011-11-08 at 15:51 +0100, Niclas Lardh wrote:

> Amongst the first things I have done is to replace all the graphics
> in the NewBoot menus.

Just tried your icons! I like them a lot!

> I plan on documenting the progress of my adventures on my site at
> http://heavyconsulting.net/c-one/
> Just ignore the long ramblings (I tend to write long and annoying
> text sometimes) and scroll down to the bottom for some screenshots
> and downloadable files with my new (work in progress) icons and
> backgrounds. I am not quite happy with them yet, but I still think
> it's an improvement over the originals.

I loved to read your "ramblings" :-) Also the explanation about the
boot.bin file. When I've developed the ZX-One core I've worked on it too
(to copy a TAP file saved in the core directory to the SDRAM accessible
by the 1K30, that, in my case, contains the tape player emulator).

After, I started to study how to modify the "selector" to select a TAP
before running the core, but in the end I left.. maybe in the future you
could find a solution to this need..

> Still, I just love to mess around with things, and hope I will be
> able to eventually contribute something.

Keep on the good work! :-)

Cheers,
Alessandro

12 nov 2011 at 11:25. Alessandro Dorigatti:

> Just tried your icons! I like them a lot!

Thank you. It's very nice to hear that. :-)

> I loved to read your "ramblings" :-) Also the explanation about the
> boot.bin file. When I've developed the ZX-One core I've worked on
> it too
> (to copy a TAP file saved in the core directory to the SDRAM
> accessible
> by the 1K30, that, in my case, contains the tape player emulator).
>
> After, I started to study how to modify the "selector" to select a TAP
> before running the core, but in the end I left.. maybe in the
> future you
> could find a solution to this need..

Unfortunately I don't have too much free time to work on this, but
today I have started to really go through what the "Selector" does,
and how it does it, along with the bootprogram and file routines in
the "ROM". I haven't worked with 6502 assembly in over ten years, but
I still seem to get the hang of it without problem. :-)

I will probably have to revise my text about the boot.bin several
times as I learn more. Remember that anything I write is based on
what I find by examining what I can, and it may very well be
completely incorrect. :-) After all, I have only been working with
the C-one for a week so far, trying to gather all the information I can.

Making a menu system that allows for selection of the TAP file, or in
the case of the FPGA64, a PRG or CRT file, would be very nice. Having
to have multiple copies of the same core directory just to be able to
have several programs to load is a little bit annoying. Especially if
you want more than 12 programs to choose from.

It should be very possible, I think, to include such a thing inside
the boot.bin of the ZX-one or FPGA64.


Sounds like a nice challenge!


By the way, has the source code of your excellent ZX-one been
released? I tried to google around a bit and found the retroleum
site, but no source anywhere. I'm just a bit curious to see it if
it's available. If not, thats ok too.
--
Niclas

On Sun, 2011-11-13 at 01:07 +0100, Niclas Lardh wrote:

> Making a menu system that allows for selection of the TAP file, or in
> the case of the FPGA64, a PRG or CRT file, would be very nice. Having
> to have multiple copies of the same core directory just to be able to
> have several programs to load is a little bit annoying. Especially if
> you want more than 12 programs to choose from.
>
> It should be very possible, I think, to include such a thing inside
> the boot.bin of the ZX-one or FPGA64.
>
> Sounds like a nice challenge!

Yes it is! In case, the ZX-One reads the TAP file starting from the
address $80000 of the SDRAM.

> By the way, has the source code of your excellent ZX-one been
> released?

No, I've never released the source code. If you are interested, please
contact me in private.

Cheers,
Alessandro

13 nov 2011 at 09:51. Alessandro Dorigatti:

> On Sun, 2011-11-13 at 01:07 +0100, Niclas Lardh wrote:
>
>> [selection menu for TAP files]
>> Sounds like a nice challenge!
>
> Yes it is! In case, the ZX-One reads the TAP file starting from the
> address $80000 of the SDRAM.

Last night I went through the code for the selector thoroughly and commented it
all through to get a good picture of it. Then I added to it the ability to show
TAP-filenames on the icons as well.

As you probably already know, the Selector, while drawing out the menu will look
in the core directories and search for a select.txt to display on the icon. If
that is not found, it will instead look for a CRT-file, a C64 cartridge file,
and extract the name of the cart from within that file to show instead. If no
cart file is found either, it will resort to showing the name of the first
PRG-file it finds in the core directory.

I added to that so that if a PRG is not found, it will scan for a TAP instead
and show that name. Makes it a lot easier to know what tape is going to be
loaded with the core, especially if you have a selector screen with lots of
ZX-one cores, all with different TAPs inside, without having to make a
select.txt for each one.

A very simple addition, but it does make a nice difference. I will post the new
Selector boot.bin on my site later tonight.

Now I just need to get to work on some nice text-menu routines to make a
selection menu.
--
Niclas
>

Hello Niclas,

your findings are very interesting and I also like your icons,although I have
not tried them on the real thing right now.
As you write,there are easier boards to start with.

I think you will know the following page that has details about the boot
process: http://c1boot.sourceforge.net/tech.html

Also Tobiflex had released the source code for the custom 6502 in one posting
here some years ago,but I do not find it right now.I am sure it is here in one
of the postings.

Have fun,
Vassilis

Hello again,

I was somewhat wrong! It seems that the 1K30 core is closed source,
but Tobiflex had posted the 1541 drive emulation code here :

http://tech.groups.yahoo.com/group/cone_cores/message/151

Greetings,
Vassilis

13 nov 2011 at 15:36 "vassilis0815":

> I think you will know the following page that has details about the boot
process: http://c1boot.sourceforge.net/tech.html

Yes, I have already read that page, but unfortunately it appears to be
describing the old CPC based classic boot system, and not the new boot.
>


I think I am starting to get a pretty good grasp on how it works though. :-)
--
Niclas

I don't know if you are aware of this program, but a couple of years
ago I made a small editor for C-1 flash cards. It can replace
backgrounds, icons and fonts.

http://sourceforge.net/projects/oneganizer/files/

- Carsten Sorensen

16 nov 2011 at 16:09, Carsten Elton Sřrensen:

> I don't know if you are aware of this program, but a couple of years
> ago I made a small editor for C-1 flash cards. It can replace
> backgrounds, icons and fonts.
>
> http://sourceforge.net/projects/oneganizer/files/

Yes, I found that already.
It's a very nice idea.
Unfortunately, the Windows exe-file was of no use to me and I have
not run it and there was no source to look at. :-)


Still, building upon that concept to make a nice graphical system to
easily add and remove cores, submenus, prg-files and other things to/
from the CF would be a pretty nice thing to have.

Especially for people who just want get up and play games on the
board. :)

Something like:
Insert blank CF, start program, click "Initialize" to format and add
basic cores.
Display cores on screen, allow for buttons to add and remove them
from simple menus.
Allow for simple creation of sub-screens with more cores and to
duplicate cores to add different PRG or TAP-files to them.
Easy option to choose background and icons.
Internet updates to cores.
And so on.

On the other hand, it's much more fun to hack around with a hex editor.
--
Niclas

On Wed, Nov 16, 2011 at 16:28, Niclas Lardh <niclas@...> wrote:
> 16 nov 2011 at 16:09, Carsten Elton Sørensen:
>> http://sourceforge.net/projects/oneganizer/files/
>
> Yes, I found that already.
> It's a very nice idea.
> Unfortunately, the Windows exe-file was of no use to me and I have
> not run it and there was no source to look at. :-)

It's on sourceforge, the source is there, I assure you :)
http://oneganizer.svn.sourceforge.net/viewvc/oneganizer/trunk/

> Still, building upon that concept to make a nice graphical system to
> easily add and remove cores, submenus, prg-files and other things to/
> from the CF would be a pretty nice thing to have.

Yes my vision at the time was exactly that. Also to have a central
repo of cores and themes that the program could download and install
to the card. To be honest I've kinda lost interest in my C-One so the
project didn't really go any further.

- Carsten Sorensen

17 nov 2011 at 13:39, Carsten Elton Sřrensen:

> On Wed, Nov 16, 2011 at 16:28, Niclas Lardh <niclas@...> wrote:
>> 16 nov 2011 at 16:09, Carsten Elton Sřrensen:
>>> http://sourceforge.net/projects/oneganizer/files/
>>
>> Yes, I found that already.
>> It's a very nice idea.
>> Unfortunately, the Windows exe-file was of no use to me and I have
>> not run it and there was no source to look at. :-)
>
> It's on sourceforge, the source is there, I assure you :)
> http://oneganizer.svn.sourceforge.net/viewvc/oneganizer/trunk/

Oh, silly me, I completely missed that since it was not as a download
archive. :-)
Very nice, but still, C-sharp is not really my language, nor is
windows my main operating system.

>> Still, building upon that concept to make a nice graphical system to
>> easily add and remove cores, submenus, prg-files and other things to/
>> from the CF would be a pretty nice thing to have.
>
> Yes my vision at the time was exactly that. Also to have a central
> repo of cores and themes that the program could download and install
> to the card. To be honest I've kinda lost interest in my C-One so the
> project didn't really go any further.

Yes, there would most likely be no point in undertaking such a huge
project any more. The number of users actively using the C-one is
probably rather small, and I'm quite sure that most of them would
know how to copy some files to a memory card anyway.

Still, there are other boards, and if such a program could be built
to be used for many different boards, or if someone designs a new "C-
two" or something in the future ... of course, such boards would
probably use a completely different boot-system anyway and need a lot
of customisation for each one.

Does anyone know how many C-one boards that have actually been sold?
How large is the audience?

I will still hack around with it, because I enjoy doing it for myself
(I will probably grow tired of it soon and find something new to
obsess over for a while though), but it would be nice to know if
there are people out there who would be interested in any new
developments.



Speaking of a "C-two", designing such a thing ... now that would be a
fun challenge. Building upon the collective knowledge gathered from
all the other boards and produce a compact and user friendly board
with all the power to run anything you would like, but still stripped
down enough to not include anything you don't need to get the price
down. With modern FPGAs and connectors ...

Then again, might just wait and get the FPGAarcade. It kind of fits
all those requirements already. And I probably will get one of those
too one day. I seem to end up buying all sorts of weird toys all the
time anyway (but usually a few years after everyone else have already
stopped playing with them). :-)
--
Niclas

On Thu, Nov 17, 2011 at 14:06, Niclas Lardh <niclas@...> wrote:
> Then again, might just wait and get the FPGAarcade. It kind of fits
> all those requirements already. And I probably will get one of those

Me too, it seems pretty close to completion. It looks like a nice
platform to continue learning VHDL on again, which I had loads of fun
with on the C-One. It seems like a more straightforward setup than the
C-One with its three FPGAs that all have to work together.

- Carsten Sorensen

On 18/11/2011 1:14 AM, Carsten Elton Sřrensen wrote:

> Me too, it seems pretty close to completion. It looks like a nice
> platform to continue learning VHDL on again, which I had loads of fun
> with on the C-One. It seems like a more straightforward setup than the
> C-One with its three FPGAs that all have to work together.

Was going to suggest exactly this. IIUC Mike has spent a lot of time
tweaking Minimig to run on it. Porting the other cores should be a doddle.

The only thing I don't like about the Replay is the fact that it has Xilinx
silicon; that's pretty much a deal breaker for me personally. But I wouldn't
discourage anyone else for that reason alone. It's a very nice board!

Fortunately for me, I have access to hardware that is actually very similar
to the Replay, with even more (Altera) FPGA grunt and DDR3 memory. It has
both USB host and device ports, an ARM micro, and DVI out. No SD/CF and no
audio though (but I could add them off-board). :( But still, I can do a
*lot* with it - probably twice the capacity of a C-One with the Cyclone-III
extender, and no hoops to jump through.

It's a pity the C-One is so dated. I was hoping the extender would breathe
more life into it, but as you point out, I suspect the number of owners is
quite small, and the number of active users even smaller again. Jens and
Tobias (in particular) have without a doubt done some great work with FPGA
emulation, held back only by the legacy hardware of the C-One.

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

At 14:06 17.11.2011 +0100, Niclas Lardh wrote:

>Still, there are other boards, and if such a program could be built
>to be used for many different boards, or if someone designs a new "C-
>two" or something in the future ... of course, such boards would
>probably use a completely different boot-system anyway and need a lot
>of customisation for each one.

Right - much more modern, USB debugging, more and faster memory, more compact
form factor with case, less power consumption - it's called "Chameleon".

>Does anyone know how many C-one boards that have actually been sold?
>How large is the audience?

Under 200 boards, where only half of them actually have the FPGA extender. Over
100 boards of the initial 296-board production run failed QC and seem beyond
repair. I have exactly 11 boards with FPGA extender left in stock. The C-One is
obviously already considered "computer history", because a Swiss computer museum
bought two of the boards earlier this year. They also have a prototype of the
C-One on display, which I have given them as a long-term loan. The "Enter"
museum is currently moving to a new, bigger location, where they will have a
grand re-opening on december 3rd: http://www.pcmuseum.ch/

>Speaking of a "C-two", designing such a thing ... now that would be a
>fun challenge.

...going on: http://tech.groups.yahoo.com/group/chameleon_64/

ciao,
--
Jens Schönfeld

18 nov 2011 at 11:05, Jens Schoenfeld:
> At 14:06 17.11.2011 +0100, Niclas Lardh wrote:
>> Still, there are other boards, and if such a program could be built
>> to be used for many different boards, or if someone designs a new "C-
>> two" or something in the future ... of course, such boards would
>> probably use a completely different boot-system anyway and need a lot
>> of customisation for each one.
> Right - much more modern, USB debugging, more and faster memory,
> more compact form factor with case, less power consumption - it's
> called "Chameleon".

Yes, I know about it. :-) That's why I recommended the Chameleon over
a C-one in the little text i wrote on my C-one page.
And I might get one of them some day, I really like the concept, but
I only have time to tinker with one thing at the time, so it will
have to wait.
But yellow is a nice colour.


>> Does anyone know how many C-one boards that have actually been sold?
>> How large is the audience?
>
> Under 200 boards, where only half of them actually have the FPGA
> extender. Over 100 boards of the initial 296-board production run
> failed QC and seem beyond repair. I have exactly 11 boards with
> FPGA extender left in stock.

That's a bit less than I thought, so I guess there are very very few
left in active use then.

> The C-One is obviously already considered "computer history",
> because a Swiss computer museum bought two of the boards earlier
> this year. They also have a prototype of the C-One on display,
> which I have given them as a long-term loan.


Yay! I own a very rare piece of computer history then. :-)
Now, if I could just get my hands on a Apple I too my life would be
complete.

Still, the C-one is very fun (although slightly frustrating) to hack
around with, so I have no regrets buying it.
And it plays my old Amiga games perfectly too, without me having to
get a new Amiga mouse. :-)
(I did buy a Mroocheck mouse adapter back in the very very early
2000s or so to rectify the mouse problem on my Amigas, but shortly
thereafter, serial PC-mice went the way of the dodo too, so it didn't
help for very long) :-)


> The "Enter" museum is currently moving to a new, bigger location,
> where they will have a grand re-opening on december 3rd: http://
> www.pcmuseum.ch/

Sounds like a nice museum. Too bad I can't get there to visit it, I
would have loved it.

--
Niclas

Hi!

Time to power up the C-One:

http://www.linusakesson.net/scene/parallelogram/index.php

Best regards,
Linus

Its nice to see some nice stuff for the shit err... c-one


On 12 April 2012 09:11, Linus Akesson <lft@...> wrote:

> **
>
>
> Hi!
>
> Time to power up the C-One:
>
> http://www.linusakesson.net/scene/parallelogram/index.php
>
> Best regards,
> Linus
>
>


[Non-text portions of this message have been removed]

This is supercool Linus! Congrats on your victory!

I was wondering if you could write/blog or document your main board
replacement? I thought that was an excellent contraption. I suspect I would
get a little more FPGA coding done with a setup like that.

Cheers,
Carsten

On Thu, Apr 12, 2012 at 10:11, Linus Akesson <lft@...> wrote:

> Hi!
>
> Time to power up the C-One:
>
> http://www.linusakesson.net/scene/parallelogram/index.php
>
> Best regards,
> Linus
>
>


[Non-text portions of this message have been removed]

On 12/04/2012 6:11 PM, Linus Akesson wrote:

> Time to power up the C-One:
> http://www.linusakesson.net/scene/parallelogram/index.php

It's impressive work, but I'm wondering... why? This demo could have easily
been coded on a PC...

Or was it purely a learning exercise for you?

On another note, could the graphics engine have any utility in the emulation
of existing systems? Would be nice to see your efforts used for something...
"useful"! (Not to take anything away from your demo, hope you don't take
offence).

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

On Thu, Apr 12, 2012 at 13:44, Mark McDougall <msmcdoug@...> wrote:

> It's impressive work, but I'm wondering... why? This demo could have easily
> been coded on a PC...
>

Why? Because that's what the demoscene is all about. Or at least it was
before it got all artsy ;)

People do all kinds of crazy stuff. They still make C64 demos. They could
easily have done those on the PC. People still make Atari 2600 games. They
could easily have done those on the PC. And, dare I say - we run C64 cores
on a C-One, we could just as well use a C64 emulator on a PC.

Best,
Carsten


[Non-text portions of this message have been removed]

On 12/04/2012 11:55 PM, Carsten Elton Sřrensen wrote:

> People do all kinds of crazy stuff. They still make C64 demos. They could
> easily have done those on the PC. People still make Atari 2600 games. They
> could easily have done those on the PC. And, dare I say - we run C64 cores
> on a C-One, we could just as well use a C64 emulator on a PC.

I can understand writing a demo - or game - for an old machine, that makes
sense. And I also 'get' hardware emulation (as opposed to software on a PC)
- after all I've done both myself.

What is a bit odd (to me) is developing a custom platform to write a demo -
that sort of defeats the purpose a bit, doesn't it? The idea of a demo is to
see who can squeeze the maximum performance out of a machine... doesn't mean
much on custom hardware though???

But I can understand if it was purely a learning experience. Would be cool
to be able to use the engine for emulation of some other retro platform...
like the N64 for example!

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

On Thu, Apr 12, 2012 at 03:55:32PM +0200, Carsten Elton Sřrensen wrote:
> On Thu, Apr 12, 2012 at 13:44, Mark McDougall <msmcdoug@...> wrote:
>
> > It's impressive work, but I'm wondering... why? This demo could have easily
> > been coded on a PC...
> >
>
> Why? Because that's what the demoscene is all about. Or at least it was
> before it got all artsy ;)
>
> People do all kinds of crazy stuff. They still make C64 demos. They could
> easily have done those on the PC. People still make Atari 2600 games. They
> could easily have done those on the PC. And, dare I say - we run C64 cores
> on a C-One, we could just as well use a C64 emulator on a PC.
>
> Best,
> Carsten

I agree, and there are two further point to be made:

First, with demos, the result that we see and hear is only the surface. The
(partial) knowledge of how the sound and visuals arise are a fundamental part
of the experience. Otherwise, why make demos at all, when offline rendering
could produce the same visuals? Similarly, why would we care about somebody
climbing Mount Everest, when any commercial flight would take them higher?

Second, the limitations of a system strongly influence the creative process,
meaning that the demo would not have turned out in this specific way if I had
been working with a PC platform.

Best regards,
Linus
-------------------------------- http://www.linusakesson.net/ ---
``Coding standards or guidelines will not make good programmers
   out of bad programmers. They have absolutely no effect at all
   on the correctness of the code that a programmer produces. You
   cannot legislate good design.''
-- Robert Martin
-----------------------------------------------------------------
WARNING! E-mail and ALL Internet Communications to and from
Sweden, or via servers in Sweden, is monitored by the National
Defence Radio Establishment (FRA).

On Thu, Apr 12, 2012 at 16:08, Mark McDougall <msmcdoug@...> wrote:

> What is a bit odd (to me) is developing a custom platform to write a demo -
> that sort of defeats the purpose a bit, doesn't it? The idea of a demo is
> to
> see who can squeeze the maximum performance out of a machine... doesn't
> mean
> much on custom hardware though???
>

You could also argue that *the C-One* is the platform to which you're
constrained. Granted, there aren't many C-One demos out there, but if there
were, they'd be competing on the same terms.

But yeah, from the perspective you present it doesn't make a lot of sense.
But does it really have to?

We're guys - we do stuff, just for the hell of it, ALL the time. "Hold my
beer while I try something..." I mean, does racing a motorcycle round and
round a track for an hour make any kind of sense? Does it actually
contribute anything other than CO2? It turns out it does - it does one
thing very well - it makes people, the rider and audience, happy.
Motorcyclists in the audience especially as they can appreciate the skill
involved. Same thing with demos and particularly Linus' demo - to make
that, you'd need skills in very diverse technical areas (which you are
aware of).

It's just an impressive achievement and I was impressed (something that's
not easy to do :)

Best,
Carsten


[Non-text portions of this message have been removed]

Hi guys,

Have been sitting with a C-one board for years and played around with the C64
cores now and then. Today I casually browsed the internet and saw Vesalia Online
still advertising the board (http://www.vesalia.de/e_commodoreone.htm). I
noticed that under external interfacing it mentioned that the PC style parallel
port it has can act as a C64 userport with adapter.

That's where I remembered that I used to hook up a C64 to a Marklin interface
(modeltrains) over the user port (found even the cable I once bought for that
purpose). Just wondered whether I can still do that with the same software I
used on the C64 or does it require opening a different port/protocol?

So basically two questions:
1) Does the original c64 Basic/assembly code need to change to make use of the
C-one (c64 core) parallel port with the use of an user port adapter?
2) Does anyone has such an parallel/user port adapter or is willing to built one
for me if the answer on question 1 is no (or simple changes only)?

Please let me know if this is the wrong forum to ask. However I couldn't think
of any other remotely active c-One forum. Maybe I should ask Jens directly?

Cheers,
Renate

Hello

If I remember correctly the Märklin Digital 3R command module used a serial
interface to communicate with the computer. It was possible to hook this up to
the C64 user port through the "serial port" available in the user port (transmit
on PA2 i think?). The Märklin interface had DIP-switches to select what you
connected it to.

Then you could open the serial port by opening channel 2 from BASIC and write to
it.
Note that this is all taken from my tired memory, and I haven't done anything
with any of this for like 20 years, so anything I write may be wrong.

The output of the C64 was "TTL" 5V and not standard RS232, but as I remember,
the Märklin interface was OK with that if configured properly. The output of
the C64 was also not a real serial port, if I remember correctly, but actually
implemented in software. There are serial outputs from the CIA-chips, but I
believe there were some bugs in them making them impossible to use properly.

The outputs of the "parallel port" of the C-one is also 5V (I hope), so
technically, it would be possible to just choose any line as data output and
write the necessary logic in the core to use it as PA2 output.

It is however currently almost 3 in the morning though, and anything I say might
be completely wrong.

Also, I don't have access to the c-one schematics right now but, I do seem to
remember that the C-one "parallel port" was not very well configured, missing
several important signals to be a full parallel port, as well as being output
only on the 8 data-bits. I think it was connected to one of the CPLDs, and I
have no idea how to reach it from the FPGA, but it shouldn't be much more
complicated than reading the joysticks.

Anyway, if you found a "user port adapter" for the c-one, it is possible that it
would not work with your interface anyway, depending on exactly what signals it
implements, and what support there is in the core. A better option would be to
implement the serial output on any IO and build a new cable for it. But to
implement the port would mean having to get and modify the source for the FPGA64
...

However, with regards to you question number 1, if the output is implemented
properly, the original basic code would work the same, just opening channel 2
and writing data.

On the other hand, you would probably be a lot better off using a real C64,
maybe with a SD2IEC, IDE64 or Chameleon to easily load the software.

Or (the boring option, I know) use a PC. :)

I assume you might have heard about or read them already, but Rutger Friberg
wrote books and a large number of articles on using the C64 with the Märklin
Digital 3R back in the day, as well as lots of model train electronics in
general. Of course, it was all in Swedish, but I think there is at least one
book translated to english if that suits you better.

Anyway, hope anything of what I have written here is any help. I don't think it
is, but ah well.

Now if I could just fall asleep before the sun gets up again ...
--
Niclas

Sent from my iPad

22 apr 2012 kl. 02:02 skrev "renate2609r" <renate2609r@...>:

> Hi guys,
>
> Have been sitting with a C-one board for years and played around with the C64
cores now and then. Today I casually browsed the internet and saw Vesalia Online
still advertising the board (http://www.vesalia.de/e_commodoreone.htm). I
noticed that under external interfacing it mentioned that the PC style parallel
port it has can act as a C64 userport with adapter.
>
> That's where I remembered that I used to hook up a C64 to a Marklin interface
(modeltrains) over the user port (found even the cable I once bought for that
purpose). Just wondered whether I can still do that with the same software I
used on the C64 or does it require opening a different port/protocol?
>
> So basically two questions:
> 1) Does the original c64 Basic/assembly code need to change to make use of the
C-one (c64 core) parallel port with the use of an user port adapter?
> 2) Does anyone has such an parallel/user port adapter or is willing to built
one for me if the answer on question 1 is no (or simple changes only)?
>
> Please let me know if this is the wrong forum to ask. However I couldn't think
of any other remotely active c-One forum. Maybe I should ask Jens directly?
>
> Cheers,
> Renate
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi,

Thanks Niclas for this extensive reply. That is helpful.
I can confirm that the cable I have acted as a serial cable and you could open
channel 2 from BASIC to write to it on the c64. Besides that Marklin delivered
some nifty assembler software that enabled you to read out the S88 feedback
modules. Still have that software and a program (mix of Basic and assembly) I
wrote myself to control the trains through the joysticks, control the switches
and signals and display a basic configuration of the model railroad layout. It
also had the ability to program multiple trains according to a fixed time-table
being triggered by the S88 feedback modules.

Also still have my old c64, so basically still have a working system. However
one of the reasons of buying the C-one was to preserve all this nice retro stuff
in a working order. So that's why I'm keen to get it to work on my C-one and not
on a PC or other configuration. I agree with you that I might be better off to
use a PC or original c64, but this is a hobby ;-)

Anyway, all you notes taken from your tired memory are right as far as I can
verify and check on the internet.
- The Marklin interface could deal with the C64 TTL 5v with dip switches which
settings can still be found on the Marklin website.
- According to their website the pins I need on the Marklin interface site are:
Pin at Interface Commodore C-64
1  RD 	 M
2  CTS 	 D
3  GND 	 N
4  TD 	 B & C
5  RTS 	 L
This sounds fairly straightforward and I think there is a fair chance that these
basics are implemented on the parallel port in the C-one core. However I hoped
that someone can confirm that so I can start the hunt for an parallel/user port
interface. Or maybe I should do that anyway and just try.

After digging further being inspired by your comments I found a Dutch website
with a lot of information. Now I'm trying to contact the owner of a Dutch
website which has some documentation on it
(http://home.planet.nl/~rvdhof/start.html). Mainly in english BTW. However he
describes an interface which requires 14 lines which doesn't sound right to me.

However the question still stands which lines of the parallel port of the C-one
board are implemented in the latest core. Trial and error might take a while, so
I'm happy to hear any experiences with this port and the C64 core implementation
or from people who wrote the core or can read the sources of it and provide me
with some answers.

Anyway thanks for your help and hope you fell asleep after writing this down ;-)

Cheers,
Renate

--- In cone_cores@yahoogroups.com, Niclas Lardh <niclas@...> wrote:
>
> Hello
>
> If I remember correctly the Märklin Digital 3R command module used a serial
interface to communicate with the computer. It was possible to hook this up to
the C64 user port through the "serial port" available in the user port (transmit
on PA2 i think?). The Märklin interface had DIP-switches to select what you
connected it to.
>
> Then you could open the serial port by opening channel 2 from BASIC and write
to it.
> Note that this is all taken from my tired memory, and I haven't done anything
with any of this for like 20 years, so anything I write may be wrong.
>
> The output of the C64 was "TTL" 5V and not standard RS232, but as I remember,
the Märklin interface was OK with that if configured properly. The output of
the C64 was also not a real serial port, if I remember correctly, but actually
implemented in software. There are serial outputs from the CIA-chips, but I
believe there were some bugs in them making them impossible to use properly.
>
> The outputs of the "parallel port" of the C-one is also 5V (I hope), so
technically, it would be possible to just choose any line as data output and
write the necessary logic in the core to use it as PA2 output.
>
> It is however currently almost 3 in the morning though, and anything I say
might be completely wrong.
>
> Also, I don't have access to the c-one schematics right now but, I do seem to
remember that the C-one "parallel port" was not very well configured, missing
several important signals to be a full parallel port, as well as being output
only on the 8 data-bits. I think it was connected to one of the CPLDs, and I
have no idea how to reach it from the FPGA, but it shouldn't be much more
complicated than reading the joysticks.
>
> Anyway, if you found a "user port adapter" for the c-one, it is possible that
it would not work with your interface anyway, depending on exactly what signals
it implements, and what support there is in the core. A better option would be
to implement the serial output on any IO and build a new cable for it. But to
implement the port would mean having to get and modify the source for the FPGA64
...
>
> However, with regards to you question number 1, if the output is implemented
properly, the original basic code would work the same, just opening channel 2
and writing data.
>
> On the other hand, you would probably be a lot better off using a real C64,
maybe with a SD2IEC, IDE64 or Chameleon to easily load the software.
>
> Or (the boring option, I know) use a PC. :)
>
> I assume you might have heard about or read them already, but Rutger Friberg
wrote books and a large number of articles on using the C64 with the Märklin
Digital 3R back in the day, as well as lots of model train electronics in
general. Of course, it was all in Swedish, but I think there is at least one
book translated to english if that suits you better.
>
> Anyway, hope anything of what I have written here is any help. I don't think
it is, but ah well.
>
> Now if I could just fall asleep before the sun gets up again ...
> --
> Niclas
>
> Sent from my iPad
>
> 22 apr 2012 kl. 02:02 skrev "renate2609r" <renate2609r@...>:
>
> > Hi guys,
> >
> > Have been sitting with a C-one board for years and played around with the
C64 cores now and then. Today I casually browsed the internet and saw Vesalia
Online still advertising the board (http://www.vesalia.de/e_commodoreone.htm). I
noticed that under external interfacing it mentioned that the PC style parallel
port it has can act as a C64 userport with adapter.
> >
> > That's where I remembered that I used to hook up a C64 to a Marklin
interface (modeltrains) over the user port (found even the cable I once bought
for that purpose). Just wondered whether I can still do that with the same
software I used on the C64 or does it require opening a different port/protocol?
> >
> > So basically two questions:
> > 1) Does the original c64 Basic/assembly code need to change to make use of
the C-one (c64 core) parallel port with the use of an user port adapter?
> > 2) Does anyone has such an parallel/user port adapter or is willing to built
one for me if the answer on question 1 is no (or simple changes only)?
> >
> > Please let me know if this is the wrong forum to ask. However I couldn't
think of any other remotely active c-One forum. Maybe I should ask Jens
directly?
> >
> > Cheers,
> > Renate
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

Hoi Renate,

--- In cone_cores@yahoogroups.com, "renate2609r" <renate2609r@...> wrote:
> However the question still stands which lines of the parallel port of the
C-one board are implemented in the latest core. Trial and error might take a
while, so I'm happy to hear any experiences with this port and the C64 core
implementation or from people who wrote the core or can read the sources of it
and provide me with some answers.
>

Ok and such a core developer would be.. ehh.. me.

There is no support for the user-port in either the FPGA-64 core nor the
Chameleon preview. There are not enough lines on the LPT port wired for a full
user-port. And as usual on the C-one there is another catch or two: Some of the
lines are multiplexed in the joystick stream. If you connect on of those lines
on the LPT, the serial sync might fail and the joysticks might stop working.
Also not all the lines are fully controllable (for technical details and a list
of all the caveats see my C-One core developer manual chapter 7.5).

I have currently no plans to add user-port support as I stopped developing cores
for the C-One hardware a while ago.

Greetz,
Peter

Hoi Peter,

Thanks for you reply, although a bit disappointing as this might stop me in my
tracks to get this to work. Did find a version of your guide as of 2 June 2009
(http://c64upgra.de/c-one/). I now start to realise the compromises which have
been made or had to be made to implement some of the I/O. Although the
programming of the joystick is well-documented so I could work around that, I'm
lacking two SIDs in my C-one. It's hard to get by these ones nowadays, but not
impossible. Might also use the keyboard instead of fancy joysticks for the
actual train movement. So have a few possible solutions in this area.

However in the documentation you referred both the paragraphs for IEC serial bus
and the Printer port state 'TODO'. Your answer implies that some lines are
actually implemented, but I'm still not wiser which ones. Is there a more recent
version of your manual available somewhere? Can I assume that the standard PC
parallel port lines are implemented in a standard layout?

Further research learned that I definitely only need 5 lines (instead of 14 or
more) of the original user port. Here are the lines I need:
pin C = RD (read data) = IN
pin D = RTS (Request to send) = OUT
pin M = TD (transmit data) = OUT
pin K = CTS (Clear to send) = IN
pin N = signal ground.

I can imagine that there won't be further development on the core, but I still
hope there is some documentation on the implemented lines for the C-one parallel
port. Together with a physical hardware wizard I might be able to extract some
useful signals out of that and get it to work.

Cheers,
Renate



--- In cone_cores@yahoogroups.com, "Peter" <pwsoft@...> wrote:
>
>
> Hoi Renate,
>
> --- In cone_cores@yahoogroups.com, "renate2609r" <renate2609r@> wrote:
> > However the question still stands which lines of the parallel port of the
C-one board are implemented in the latest core. Trial and error might take a
while, so I'm happy to hear any experiences with this port and the C64 core
implementation or from people who wrote the core or can read the sources of it
and provide me with some answers.
> >
>
> Ok and such a core developer would be.. ehh.. me.
>
> There is no support for the user-port in either the FPGA-64 core nor the
Chameleon preview. There are not enough lines on the LPT port wired for a full
user-port. And as usual on the C-one there is another catch or two: Some of the
lines are multiplexed in the joystick stream. If you connect on of those lines
on the LPT, the serial sync might fail and the joysticks might stop working.
Also not all the lines are fully controllable (for technical details and a list
of all the caveats see my C-One core developer manual chapter 7.5).
>
> I have currently no plans to add user-port support as I stopped developing
cores for the C-One hardware a while ago.
>
> Greetz,
> Peter
>

Hoi Renate,

Yes there is a newer version of the document. The latest version (from july
2010) is available on my website at http://syntiac.com/c_one.html

A direct download link to the document:
http://syntiac.com/pdf/cone_core_development.pdf

There are 8 data pins available on the printer port that can be set to either
input or output individually. Then there is "strobe", which is almost completely
controllable. The rest of the lines on the port are either kinda messy to use or
not connected at all.

Joysticks would make a cool I/O port as well, but these are input only on the
C-One. I think the best alternative for some spare I/O lines is using some of
the signals from the PCI slot(s). That should offer about 30 lines of additional
I/O I think. These are directly connected to the 1k100 FPGA so easy to control
form a core.

I guess your best bet is starting (or let somebody start) from FPGA-64 as it
runs on the 1k100 and so has access to most I/O lines. Older versions of FPGA-64
core are open-source. Someone more or less competent in VHDL should be able to
hack something in there. The FPGA is nearly full with that design though! So
there is not really much room for additions, but an simple I/O port should fit.

SIDs chips are not required if you can live without sound (and analog paddle
inputs). The C-One works without them just the same.

Hope it helps.

Doei!
Peter

--- In cone_cores@yahoogroups.com, "renate2609r" <renate2609r@...> wrote:
>
> Hoi Peter,
>
> Thanks for you reply, although a bit disappointing as this might stop me in my
tracks to get this to work. Did find a version of your guide as of 2 June 2009
(http://c64upgra.de/c-one/). I now start to realise the compromises which have
been made or had to be made to implement some of the I/O. Although the
programming of the joystick is well-documented so I could work around that, I'm
lacking two SIDs in my C-one. It's hard to get by these ones nowadays, but not
impossible. Might also use the keyboard instead of fancy joysticks for the
actual train movement. So have a few possible solutions in this area.
>
> However in the documentation you referred both the paragraphs for IEC serial
bus and the Printer port state 'TODO'. Your answer implies that some lines are
actually implemented, but I'm still not wiser which ones. Is there a more recent
version of your manual available somewhere? Can I assume that the standard PC
parallel port lines are implemented in a standard layout?
>
> Further research learned that I definitely only need 5 lines (instead of 14 or
more) of the original user port. Here are the lines I need:
> pin C = RD (read data) = IN
> pin D = RTS (Request to send) = OUT
> pin M = TD (transmit data) = OUT
> pin K = CTS (Clear to send) = IN
> pin N = signal ground.
>
> I can imagine that there won't be further development on the core, but I still
hope there is some documentation on the implemented lines for the C-one parallel
port. Together with a physical hardware wizard I might be able to extract some
useful signals out of that and get it to work.
>
> Cheers,
> Renate
>

Hoi Peter,

Thanks for your link. Need to talk to a few people about the 8+1 data lines
available. See if we can address those somehow from within the core. Taking
lines from the PCI port sounds really geeky and complicated to interface with,
but thanks for the ideas.

While looking at your site, I think it's a pity that there is nothing on the
Turbo Chameleon hardware I could find what could be used for a two-way serial
interface. Happy to move to that platform as it is likely to be a more active
development platform going forward. But maybe I should open a thread in the
chameleon groups asking for more scope creep ;-)

Cheers en groeten,
Renate

--- In cone_cores@yahoogroups.com, "Peter" <pwsoft@...> wrote:
>
> Hoi Renate,
>
> Yes there is a newer version of the document. The latest version (from july
2010) is available on my website at http://syntiac.com/c_one.html
>
> A direct download link to the document:
> http://syntiac.com/pdf/cone_core_development.pdf
>
> There are 8 data pins available on the printer port that can be set to either
input or output individually. Then there is "strobe", which is almost completely
controllable. The rest of the lines on the port are either kinda messy to use or
not connected at all.
>
> Joysticks would make a cool I/O port as well, but these are input only on the
C-One. I think the best alternative for some spare I/O lines is using some of
the signals from the PCI slot(s). That should offer about 30 lines of additional
I/O I think. These are directly connected to the 1k100 FPGA so easy to control
form a core.
>
> I guess your best bet is starting (or let somebody start) from FPGA-64 as it
runs on the 1k100 and so has access to most I/O lines. Older versions of FPGA-64
core are open-source. Someone more or less competent in VHDL should be able to
hack something in there. The FPGA is nearly full with that design though! So
there is not really much room for additions, but an simple I/O port should fit.
>
> SIDs chips are not required if you can live without sound (and analog paddle
inputs). The C-One works without them just the same.
>
> Hope it helps.
>
> Doei!
> Peter
>
> --- In cone_cores@yahoogroups.com, "renate2609r" <renate2609r@> wrote:
> >
> > Hoi Peter,
> >
> > Thanks for you reply, although a bit disappointing as this might stop me in
my tracks to get this to work. Did find a version of your guide as of 2 June
2009 (http://c64upgra.de/c-one/). I now start to realise the compromises which
have been made or had to be made to implement some of the I/O. Although the
programming of the joystick is well-documented so I could work around that, I'm
lacking two SIDs in my C-one. It's hard to get by these ones nowadays, but not
impossible. Might also use the keyboard instead of fancy joysticks for the
actual train movement. So have a few possible solutions in this area.
> >
> > However in the documentation you referred both the paragraphs for IEC serial
bus and the Printer port state 'TODO'. Your answer implies that some lines are
actually implemented, but I'm still not wiser which ones. Is there a more recent
version of your manual available somewhere? Can I assume that the standard PC
parallel port lines are implemented in a standard layout?
> >
> > Further research learned that I definitely only need 5 lines (instead of 14
or more) of the original user port. Here are the lines I need:
> > pin C = RD (read data) = IN
> > pin D = RTS (Request to send) = OUT
> > pin M = TD (transmit data) = OUT
> > pin K = CTS (Clear to send) = IN
> > pin N = signal ground.
> >
> > I can imagine that there won't be further development on the core, but I
still hope there is some documentation on the implemented lines for the C-one
parallel port. Together with a physical hardware wizard I might be able to
extract some useful signals out of that and get it to work.
> >
> > Cheers,
> > Renate
> >
>