 Previous Messages |
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!
|
|
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
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
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 
|
|
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
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
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 
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
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
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
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
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
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: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
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
13:54:10
| Re: Looking for collaborator
What is the most common file format for multicolour images on Plus/4?
|
|
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
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!
|
|
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
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
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
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
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
04:41:14
| Re: Looking for collaborator
Are there any kind of REU:s or something similar that work with Plus/4?
|
|
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
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
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
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
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
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
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
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
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
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
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-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
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
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
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
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
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 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-09-17
10:53:27
| Re: Looking for collaborator
Well thank you. Johan and I, who wrote Ozmoo, also wrote PunyInform.
|
|
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: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
|
|
