Login
Back to forumReply to this topicGo to last reply

Posted By

fredrikr
on 2020-09-17
10:05:30
 Looking for collaborator

I'm an experienced C64 programmer looking for an experienced Plus/4 programmer to cooperate with to port a C64 project to the Plus/4.

I'd like to find someone who is willing to invest a bit of time into this, probably like 20-40 hours.

The project is a Z-code interpreter - a program to run Infocom games and newer games using the same game format. It's a GPL:ed open source project. No money involved.

I tried including the link to the Github page for the project, but that made the site classify my post as spam and not accept it. Google Ozmoo to find it.

You can answer here or mail me at fredrik dot ramsberg at gmail dot com

Posted By

Luca
on 2020-09-17
10:24:01
 Re: Looking for collaborator

It reminds something we've recently see: PunyInform, producing the pretty nice interface we've seen in Behind Closed Doors 9B.

Posted By

fredrikr
on 2020-09-17
10:53:27
 Re: Looking for collaborator

Well thank you. Johan and I, who wrote Ozmoo, also wrote PunyInform.

Posted By

KiCHY
on 2020-10-22
04:47:45
 Re: Looking for collaborator

I think the lack of response was because we don't have that 20-40 hours, next to Life, our own projects, and Everything happy But feel free to ask questions here, there are several ppl here who already converted games from C64 to +4.

Oh, and the missing GitHub URL is:
https://github.com/johanberntsson/ozmoo

Posted By

fredrikr
on 2020-10-23
05:40:49
 Re: Looking for collaborator

That may be so.

We're almost done now anyway.

Any suggestions on how to get a good random seed on the Plus/4? On the C64, you can read the output of a noise generator in the SID. Is there something better than the real time clock on the Plus/4?

Posted By

Luca
on 2020-10-23
06:06:22
 Re: Looking for collaborator

Nah, we basically do the same: TED Sound Generation Internals.

Posted By

KiCHY
on 2020-10-23
08:52:28
 Re: Looking for collaborator

The useful answer is: there is no similar solution in plus/4.
We usually use the timer ($FF00), perhaps combined with raster value ($FF1D) with EOR or ADC. The smarter ones also utilize a software counter intervened by a user keypress. This last one is important when the PRG is started with an emulator and that emulator "ensures" the very same timer/raster environment with each run.

Posted By

Gaia
on 2020-10-23
09:25:00
 Re: Looking for collaborator

Perhaps the "most" random of all number sources is the horizontal raster counter $FF1E which in itself is not ideal as it tends to give back repeating patterns unless the screen is disabled. Here you can find a few more tips:

forum/17395#17400

Posted By

Luca
on 2020-10-23
12:10:23
 Re: Looking for collaborator

Yes Gaia, I used that in order to cross two variable values with non comparable frequency, and actually it worked quite good for a fire effect. Hope to fall into the "useful" signed hat with this answer.

Posted By

fredrikr
on 2020-10-24
04:42:08
 Re: Looking for collaborator

How can I turn off the function keys' predefined strings so I can use these keys in a program?

Posted By

KiCHY
on 2020-10-24
06:59:23
 Re: Looking for collaborator

You can set the lengths of these 8 texts at address $55F-566. Simply write eight zeroes from this address. If you want to redefine them to some special one-letter value so your program can react, set their lengths to 1s, and the area 0567-05E6 contains their text definitions. The strings here are packed, so your eight single-letter strings occupy exactly 8 bytes from $567.
In MONITOR, type
>055F 01 01 01 01 01 01 01 01
>0567 41 42 43 44 45 46 47 48
and the function keys will write A, B, C...


Posted By

fredrikr
on 2020-10-26
09:13:19
 Re: Looking for collaborator

Thanks, I got the functions keys to work now!

I read that you can make a PAL Plus/4 go into NTSC mode and thus get a 2.22 MHz clock by turning off the screen. I did this, and I could measure a 33% shorter execution time for a ML test program, compared to when the screen was on. I tested this in Vice.

Shouldn't the difference be a lot bigger than 33%?

Posted By

gerliczer
on 2020-10-26
10:01:05
 Re: Looking for collaborator

No. With turning off the screen you turn off the screen, nothing more. You should set the TED to NTSC mode to get the additional speed gain. And forget VICE. Use YAPE or plus4emu.

Posted By

fredrik
on 2020-10-26
10:12:44
 Re: Looking for collaborator

Thanks. And how do I set it to NTSC mode? My (evidently incorrect) guess it to set bit 6 in $ff07.

Posted By

siz
on 2020-10-26
10:39:23
 Re: Looking for collaborator

That's right. But I strongly advise against setting that bit as that can cause problems because the video clock crystal (and the KERNAL ROM) is different in the PAL and NTSC machines.
The proper way of handling PAL and NTSC is to keep that bit untouched:
lda $ff07
and #$40
ora #yourvalue
sta $ff07

Or save the value at initialization time:
lda $ff07
and #$40
sta palntscflag
...
and when you want to write $ff07
lda #yourvalue
ora palntscflag
sta $ff07

There are some edge cases (a bit faster CPU clock) when you can set this bit intentionally but in that case you won't have picture.

Posted By

gerliczer
on 2020-10-26
14:30:22
 Re: Looking for collaborator

@fredrikr: Your guess is right. However, it will result in significantly different user experience when your programme is run on different machines (as in PAL or NTSC). Would that be acceptable?

@siz: But he wants to use NTSC mode in a PAL system for speeding up something. That's his expressed intention. He already mentioned turning of the screen, so he must be aware of the side-effect, too.

Posted By

fredrikr
on 2020-10-26
12:11:47
 Re: Looking for collaborator

Actually, the faster CPU clock is exactly what I'm after. I want to speed up a decrunching step, and I'm totally fine with the picture being blank. I won't be making any calls to ROM routines, and I wouldn't mind disabling interrupts either.

Is there a risk of damaging the computer, or making it unstable by temporarily switching to NTSC mode?

Posted By

fredrikr
on 2020-10-26
12:16:06
 Re: Looking for collaborator

What kind of difference in user exerience? I blank the screen, enter NTSC mode unless it's already in NTSC mode, do my decrunching, switch back to PAL mode if it was originally in PAL mode and turn the screen back on. Wouldn't that look the same on PAL and NTSC?

Posted By

gerliczer
on 2020-10-26
14:30:08
 Re: Looking for collaborator

Where that kind of performance gain which can be achieved with that trickery makes observable difference the crunch time should be quite significant. So you make an NTSC guy wait for about 20 per cent longer than the PAL guy. Not that I'd really mind.

Posted By

siz
on 2020-10-26
15:02:58
 Re: Looking for collaborator

Sorry. I have seen only the last post. :/

I'm still strongly against switching between PAL and NTSC modes as my display loses sync every time that happens and I have to reset it manually. And that's me only but whenever that happens I immediately delete the stuff doing that.

Posted By

fredrikr
on 2020-10-26
18:47:54
 Re: Looking for collaborator

Oh dear, having to fiddle with your display after a switch doesn't sound nice at all. Does this happen even if the display is blanked when the switch happens?

Posted By

fredrikr
on 2020-10-27
04:41:14
 Re: Looking for collaborator

Are there any kind of REU:s or something similar that work with Plus/4?

Posted By

KiCHY
on 2020-10-27
05:17:27
 Re: Looking for collaborator

The blank screen is still a "screen" with the color of the border, so it may lose that sync.
Plus/4 has no REU or similar things.

Posted By

fredrikr
on 2020-10-27
05:49:36
 Re: Looking for collaborator

Ok, thanks. No NTSC tricks then. And we'll remove REU support, saving a few bytes.

Is the character set the same as for C64?

Is there a way to store a custom character set at the bottom or top of Basic RAM ($1000 or $f800)?

We would be happy to have some testers try out the Plus/4 interpreter now, both on emulator and on real hardware.

Posted By

KiCHY
on 2020-10-27
06:37:17
 Re: Looking for collaborator

Plus/4 has the same characters and PETSCII symbols as the C64. You can place your custom charset anywhere your memory layout allows, but in $0800 pages. $1000, $1800, $2000, etc. You can place the charset to $F800 as well, but ram ends at $FD00 so you'll lose the last 96 character data.
Use $FF12 and $FF13 for this feature.

Posted By

fredrikr
on 2020-10-27
17:03:43
 Re: Looking for collaborator

Thanks a bunch, I got the custom character set to work quite nicely!

Anyone up for testing?

Posted By

Csabo
on 2020-10-27
17:14:08
 Re: Looking for collaborator

If you put up a PRG or D64 somewhere, I'm sure quite a few of us would check it out (via emulators). Testing it on the real iron is harder, there are a few folks around who can do it but I don't want to speak for them.

Otherwise, as a rule of thumb: unless you're doing something very, very tricky stuff - if it runs fine on YAPE and Plus4Emu, it's good to go.

Posted By

Mad
on 2020-10-27
19:07:29
 Re: Looking for collaborator

An "addition" to the REU question. Kichy is right, but there are memory expansions for the C16/Plus4 with 256k and more. It's called Hannes or Csory expansions.. But they have to be "mounted" statically (soldering and so on as far as I remember). If you go for these kind of expansions go for the Hannes ones. I did start a poll on which memory expansions are available and used and it turned out that the most used is the Hannes one.. But I guess around 10 users maximally with that currently. There is also the Sidekick264 Module which supports virtual memory through a NEORAM (almost same as Georam) interface (which is pretty cool to code)..

The Hannes expansion is relatively hard to code.. Since the interrupt vectors at $fffe/$ffff also change and you only have a small stripe of persistent memory (either $1000 or $4000 bytes).. Meaning it does change almost all of the memory at selection of another "page"..

With all that, I am somehow with Kichy saying that you don't need REU support on the plus/4..

All t3h best! happy

Posted By

fredrikr
on 2020-10-29
05:11:45
 Re: Looking for collaborator

Thanks for the summary on memory expansions. With so few using these memory expansions, I don't think we'll bother with it.

We have a few people testing on real hardware now.

This interpreter will probably be used for upcoming commercial releases for the Plus/4, and will definitely be available for anyone who wants to play Z-code games on their Plus/4.

You can use Ozmoo Online to build games for the C64. I can't post links, so google it. It will soon have support for the Plus/4 too.

Posted By

fredrikr
on 2020-11-11
13:54:10
 Re: Looking for collaborator

What is the most common file format for multicolour images on Plus/4?

Posted By

Luca
on 2020-11-11
14:01:36
 Re: Looking for collaborator

Multi Botticelli. Also included in the most common modern PC crossgraphics tools, like Multipaint.

Posted By

fredrikr
on 2020-11-11
16:10:44
 Re: Looking for collaborator

Ok, thanks, I found docs on that format.

I want to show a multicolour bitmap image located at $c000, with luminance at $e400 and colour at $e000. I do this:

; Set bitmap address to $c000
lda #$30
sta $ff12

; Set luminance/colour address to $e000/$e400
lda #$e0
sta $ff14

; Set graphics mode

lda $ff07
ora #%00010000
sta $ff07

I just see garbage on screen. What am I doing wrong?

Posted By

Chronos
on 2020-11-11
16:13:26
 Re: Looking for collaborator

The easiest way to draw something on pc in your favourite gfx app (320x200) (or/and resize to 160x200 and then back to 320x200) and then use a converter: plus4emu's "p4fliconvgui" or "pixel polizei".

Posted By

fredrikr
on 2020-11-11
16:20:31
 Re: Looking for collaborator

I drew a test image in multipaint and exported it as Multi Botticelli.

I can't just show the image using some program. The image is to be used as a loader image, while a program is loading at $1001, so the image and colour data must be located as high up in memory as possible, in order to not be in the way.

Posted By

Luca
on 2020-11-11
17:31:08
 Re: Looking for collaborator

I see you didn't set bit4 of $FF06 (same as $D011 on C64):

LDA #$3B
STA $FF06

Two notes more:
- preserve the first two bits of $FF12 (due music possibly running, they're high bytes of one of the two channels)
LDA $FF12
AND #$03
ORA #$F0
STA $FF12

- keep it both PAL/NTSC compatible:
LDA $FF07
AND #$40 ; bit6 for PAL/NTSC
ORA #$18 ; bit4 for multicolor
STA $FF07

Posted By

fredrikr
on 2020-11-11
17:53:29
 Re: Looking for collaborator

No music is playing.

Since I don't touch bit 6 in ff07, i already preserve it, no?

Isn't bit 2 in $ff12 supposed to control whether TED reads image date from RAM or ROM?

If I write to $ff3f, I first have to disable interrupts, and keep them disabled until I write to $ff3e right? So that means normal Kernal interrupts can't be enabled while an image is shown on screen?

Posted By

fredrikr
on 2020-11-11
18:05:24
 Re: Looking for collaborator

Setting $ff06 to $3b finally made the image show. The image data is correct, but the colours are all wrong. Looks like random data for colours, so I'm guessing it's reading it from ROM.

Posted By

Luca
on 2020-11-11
18:18:35
 Re: Looking for collaborator

A simple STA $FF3F and everything will go, no need to disable IRQs wink

Btw, if you LDA/STA a value into $FF07, you force the PAL/NTSC settings, not preserving the original one; that code is needed to keep the bit6 with you. My fault, I didn't read the LDA/ORA/STA, you did it that good ;)

Posted By

fredrik
on 2020-11-12
04:27:19
 Re: Looking for collaborator

That's interesting.

I keep getting CPU jams if I skip SEI before storing into $ff3f.

And I can see that the Basic routines to read from RAM do SEI:

.C:0479 78 SEI
.C:047a 8D 3F FF STA $FF3F
.C:047d A0 00 LDY #$00
.C:047f B1 3B LDA ($3B),Y
.C:0481 8D 3E FF STA $FF3E
.C:0484 58 CLI
.C:0485 C9 3A CMP #$3A
.C:0487 B0 0A BCS $0493
.C:0489 C9 20 CMP #$20
.C:048b F0 E6 BEQ $0473
.C:048d 38 SEC
.C:048e E9 30 SBC #$30
.C:0490 38 SEC
.C:0491 E9 D0 SBC #$D0
.C:0493 60 RTS
.C:0494 8D 9C 04 STA $049C
.C:0497 78 SEI
.C:0498 8D 3F FF STA $FF3F
.C:049b B1 00 LDA ($00),Y
.C:049d 8D 3E FF STA $FF3E
.C:04a0 58 CLI
.C:04a1 60 RTS

But this is in fact not necessary at all? Or do I misunderstand something here?

Posted By

SVS
on 2020-11-12
04:40:50
 Re: Looking for collaborator

You need to temporary disable the IRQ because an IRQ-call might snap while you are reading RAM. In this case the jump to IRQ-routine address would not find the routine code.

Posted By

Luca
on 2020-11-12
07:46:42
 Re: Looking for collaborator

Oops, my fault fredrik, I didn't get the picture of what your intended to do, and accidentally put you on the wrong way happy

Posted By

siz
on 2020-11-12
09:57:46
 Re: Looking for collaborator

As far as I remember there are two buttons in MultiPaint for saving: the save button saves a self-executable compressed PRG and the export button saves a raw Multi-Botticelli file. Don't try to use the former one in your program.

Edit: reading further posts I see that your image is displayed properly. In that case I think you should set $ff13 to zero to instruct TED to read data from RAM instead of ROM.

Posted By

Litwr
on 2020-11-12
15:23:42
 Re: Looking for collaborator

It is quite interesting to get C+4/.PAL picture produced in NTSC mode. IMHO a multisync monitor can do this trick.

Posted By

fredrikr
on 2020-12-18
19:28:05
 Re: Looking for collaborator

And Ozmoo for Plus/4 is now out!

You can now build games for Plus/4 at http://microheaven.com/ozmooonline/

Huge thanks for the helpful attitude and all the replies I got here!



Back to topReply to this topic


Copyright © Plus/4 World Team, 2001-2024