Beyond Super Gold Card

A place to discuss general QL issues.
User avatar
tofro
Font of All Knowledge
Posts: 2679
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Beyond Super Gold Card

Post by tofro »

I did a quick check: DIY TK "Channels" actually uses SD.EXTOP. That's safe and means the returned values should be OK. SCR_BASE should also return the proper value on any platform that has it.

The following should paint a diagonal white line across the screeen on QPC2 in 16-bit color mode (shouldn't be used in a real program as it makes way too many assumptions on screen modes and bits/pixel)

Code: Select all

100 x= 0 : y = 0 : col = $ffff
1000 REPeat Loop
1005   REMark *2 because of word pixel size in MODE 32
1010   IF (x >= (SCR_XLIM * 2)) OR (y >= SCR_YLIM) THEN EXIT Loop
1020   POKE_W SCR_BASE + x * 2 + y * SCR_XLIM * 2, col
1030   x = x + 1 : y = y + 1
1040 END REPeat


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
stevepoole
Super Gold Card
Posts: 710
Joined: Mon Nov 24, 2014 2:03 pm

Re: Beyond Super Gold Card

Post by stevepoole »

Hi Derek,
Here is my new (rich text file) PASTEable version of the 'forgotten stipples' program, from WordPad. Do not LRUN it : LOAD it and type 'start' (to set up the channels), then RUN.
Hit the 's' key to cycle through new hues ; OR 'q' key to cycle through QL stipples ; OR 'n' key to input any hue you care to think of.
After the 'n' key, enter the colour numbers of each of four pixels making up the stipple... Escape by entering '8'...
I have tested the program on QPC and SGC. WMON is not necessary unless you have run other programs beforehand !
The idea of the program is to show the new hues, allowing you to compare them to normal QL stipples. Not a utility....
Best Wishes,
Steve.

100 REMark stipples2_bas by S.Poole v10jan2020
110 REMark type 'start' & enter !
120 WMON: WINDOW 512,256,0,0: CLS
130 cmd=0: TVn=1: prg=2: prt=3: clp=4: dot=5: chk=6
140 black=0: white=7: i1=0: i2=7: grey=251
145 all=255: hues=black+7: contrast=4
150 WINDOW#TVn,464,212,24,4 : CLS
160 WINDOW#prg,464,100,24,116
170 WINDOW#prt,420,250,24,4
180 WINDOW#clp,464,108,24,4
190 WINDOW#dot,200,96,55,96
200 WINDOW#chk,128,96,296,96
210 FOR chan=cmd TO chk
220 BORDER#chan,0: PAPER#chan,grey: INK#chan,2 : STRIP#chan,black
230 END FOR chan: CSIZE#cmd,1,1
240 CLS#cmd: CLS#TVn: RESTORE
250 DIM hue$(hues,LEN('magenta')): AT 4,3
255 FOR hue=black TO hues
256 READ hue$(hue): STRIP hue: INK hue+4: PRINT hue!hue$(hue)!!
258 END FOR hue: AT 6,3
260 DATA 'black','blue','red','magenta'
270 DATA 'green','cyan','yellow','white'
280 PRINT"or Keys: 's'=Show new colours, 'n'=Nuances, 'q'=QL stipples(ESC)"
290 AT 1,21: PRINT'> If cursor flashes: input colour number 0 to 7, (esc=8)'
300 now=99: SCAN=0: F1=2: ESC=8: h=1: z=96: md=8
310 i=1: w=1: wd=w*1: i1=0: ct=0
320 FOR TL=i1 TO i2 STEP i
330 FOR TR=TL TO i2 STEP i
340 FOR LL=TR TO i2 STEP i
350 FOR LR=LL TO i2 STEP i
360 IF NOT QL_stipples
370 highlight 1,4,TL: highlight 1,12,TR
380 highlight 2,4,LL: highlight 2,12,LR
390 ct=ct+1: AT#cmd,0,8: PRINT#cmd,ct: z=0: draw_pixels
395 AT 19,10: PRINT'Show all'
400 REPeat rp
410 is$=INKEY$(-1): IF is$='q': check_QL_colours: is$=INKEY$(-1)
420 IF is$='n': nuance: is$=INKEY$(500):
430 AT 19,10: PRINT'Show all'
435 IF is$='s': AT 19,10: PRINT'Show all': EXIT rp
440 END REPeat rp
450 END IF
460 END FOR LR
470 END FOR LL
480 END FOR TR
490 END FOR TL: STOP
500 :
510 DEFine PROCedure nuance
515 AT 19,10: PRINT' ': AT 19,25: PRINT'nuances'
520 REPeat loop
530 TL=grab (1,4): IF TL=8: TL=0: AT 19,25: PRINT' ':RETurn
540 TR=grab(1,12): LL=grab (2,4): LR=grab (2,12)
550 z=100: draw_pixels
560 END REPeat loop
570 END DEFine
580 :
590 DEFine FuNction grab(rows,cols)
600 AT#TVn,rows,cols-1: INPUT#TVn,i$
610 SELect CODE(i$):=48 TO 56: =REMAINDER : GO TO 600
620 IF '8' INSTR i$: AT 19,10: PRINT'Show all': RETurn 8: ELSE ipt=i$
630 AT#TVn,rows,cols: INK#TVn,7: STRIP#TVn,0: PRINT#TVn,' '
640 ik$=hue$(ipt): STRIP#TVn,ipt: INK#TVn,ipt+4
645 AT#TVn,rows,cols: PRINT#TVn,' '
650 AT#TVn,rows,cols: PRINT#TVn,ik$: RETurn ipt
670 END DEFine
680 :
690 DEFine PROCedure highlight(row,col,tint)
700 STRIP#prt,tint: INK#prt,tint+contrast
710 AT#prt,row,col: PRINT#prt,' '
720 AT#prt,row,col: PRINT#prt,hue$(tint+(md=4 AND tint=6))
725 END DEFine
730 :
740 DEFine PROCedure check_QL_colours
745 AT 19,10: PRINT' ': AT 19, 50: PRINT 'QL stipples'
750 FOR hue=i1 TO all STEP i
760 AT#cmd,1,36: PRINT#cmd, ' '
770 PAPER #chk,hue: CLS#chk: AT #cmd,1,36: PRINT#cmd,hue: PAUSE -1
780 IF KEYROW(1)=ESC
785 AT 19,10: PRINT'Show all':AT 19,50: PRINT' ': RETurn
787 END IF
790 END FOR hue: GO TO 750
795 END DEFine
800 :
810 DEFine PROCedure draw_pixels
820 w=1: h=1
830 FOR x=0+z TO 95+z STEP 2
840 FOR y=0 TO 95 STEP 2
850 BLOCK#dot,w,h,x,y,TL: BLOCK#dot,w,h,x+1,y,TR
860 BLOCK#dot,w,h,x,y+1,LL: BLOCK#dot,w,h,x+1,y+1,LR
870 END FOR y: END FOR x: END DEFine
880 :
890 DEFine FuNction QL_stipples
900 tac=TL=TR: lac=LL=LR: IF tac*lac: RETurn 1
910 dg1=TL=LR: IF tac*dg1: RETurn 1: ELSE IF lac*dg1: RETurn 1
920 dg2=LL=TR: IF tac*dg2: RETurn 1: ELSE IF lac*dg2: RETurn 1
930 IF dg1*dg2: RETurn 1: ELSE ldn=TL=LL: rdn=TR=LR: IF ldn*rdn: RETurn 1
940 RETurn 0: END DEFine
950 :
960 DEFine PROCedure start
970 cmd=0: TVn=1: prg=2: prt=3: clp=4: dot=5: chk=6: base=0
980 FOR channel=prt TO chk: OPEN#channel,scr
990 END DEFine


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Beyond Super Gold Card

Post by Dave »

Getting back on topic....

Is there a possibility to use a physical CPU (eg: 68EC030 or 040?) with the non-68000 parts of the Q68 FPGA core? This would use a stock CPU, and the FPGA's graphics/IO capability. I imagine the main thing that would change after eliminating the 68K core would be some provision for memory - as only a small amount of RAM for IO would need to be implemented. Video accesses could be widened to 16- pr 32-bits (they may internally be 16-bit already)...

40MHz 68EC030s are around $3.00, and 68EC040s around $7. I suspect a 40MHz 68030 would handily beat a 40MHz equivalent 68000, and an 040 might be 4x faster again at the same clock.

The other enhancement would be to implement video with either DPRAM or proper VRAM - VRAM would be a cheaper/larger solution but more complex to develop while DPRAM would be more expensive and limited but a lot easier to implement.

Just musing aloud - this might be an 'easier' way of implementing a faster >SGC or future Q68-style system.


User avatar
Peter
QL Wafer Drive
Posts: 1948
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Post by Peter »

Dave wrote:Is there a possibility to use a physical CPU (eg: 68EC030 or 040?) with the non-68000 parts of the Q68 FPGA core?
Technically, yes. Using a 68EC060 instead of the internal core was always an option I held open, in case debugging the FPGA CPU failed.
With the pin shortage of a TQPF 144 package, that would have required a daughter board with a few extra logic chips to do some multiplexing.
Dave wrote:40MHz 68EC030s are around $3.00, and 68EC040s around $7.
A modern FPGA like the LFE5U-12 (50% larger than Q68 now) is $5 though.
Dave wrote:I suspect a 40MHz 68030 would handily beat a 40MHz equivalent 68000, and an 040 might be 4x faster again at the same clock.
Keep in mind the the Q68 is not a 68000 @ 40MHz equivalent: viewtopic.php?f=2&t=2637
If more fast SRAM was used, or cache added, it might even rival a 68040 for usual QL code.
Dave wrote:The other enhancement would be to implement video with either DPRAM or proper VRAM - VRAM would be a cheaper/larger solution but more complex to develop while DPRAM would be more expensive and limited but a lot easier to implement.
Even just separating video and main storage into two standard SDRAM chips with separate busses would bring a massive speed improvement for highres/-colour.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Beyond Super Gold Card

Post by Dave »

The entirety of my comment comes from one simple fact: the available 68k cores for use in FPGAs that are cycle-accurate and complete enough to run QL operating systems are limited to 68000 implementations, with no instruction or data cache and no 32-bit external accesses. It seems using an external CPU is more likely to happen than that such a CPU would be reconstructed inside an FPGA.

That said, if it WERE implemented in an FPGA, there's a far better potential for higher clocks - but we were never *that* hung up on performance, where we? :D

I really like the idea of video RAM being separated from main memory - cycle stealing for video being one of the main difficulties of the original QL design.

I also note that the relative speeds of 68K CPUs took their big leap at the 040. The 030 and prior were significantly slower per clock. There would be quite a development burden in getting the existing Q68 logic to work with the 040 and above compared to the 030 and below - so I pitched it as a stepping stone. An 030 would make a nice Q68+, whereas an 060 would create quite a different beast.

Now, I'm muddying the waters by mentioning Q68-type functionality, but this is relevant to a SGC successor as the QL need not be used for anything except keyboard input. This could be achieved by something as simple as a membrane to PS/2 adaptor to support your existing PS/2 port. A Q68 with external SD slots like the QL-SD would be a worthy SGC system internal replacement.

You have so many options, but limited time. You're requesting input, so you seemingly want to do something further than you have. Anything I can do to support or encourage that, even if it is just cheerleading from the sidelines, you have my 100% support.

PS: Tried designing a QL replacement PCB. It's a lot harder than some would think. I hold Peter in VERY high regard. And he's done it multiple times in different ways.


User avatar
Peter
QL Wafer Drive
Posts: 1948
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Post by Peter »

Dave wrote:The entirety of my comment comes from one simple fact: the available 68k cores for use in FPGAs that are cycle-accurate and complete enough to run QL operating systems are limited to 68000 implementations, with no instruction or data cache and no 32-bit external accesses.
Is there any point in cycle accuracy, unless one wants to mimic a 68008 at original QL speed?
Dave wrote:I really like the idea of video RAM being separated from main memory - cycle stealing for video being one of the main difficulties of the original QL design.
At the moment, that seems primarily an issue of BGA soldering to me.
Dave wrote:An 030 would make a nice Q68+, whereas an 060 would create quite a different beast.
As soon as I get cache working, a 68030 loses out in terms of speed. Even without cache, I'd still prefer an FPGA+SRAM design over anything less than a 060.
Dave wrote:Now, I'm muddying the waters by mentioning Q68-type functionality, but this is relevant to a SGC successor as the QL need not be used for anything except keyboard input.
Just maybe microdrives, depending on taste.
Dave wrote:This could be achieved by something as simple as a membrane to PS/2 adaptor to support your existing PS/2 port. A Q68 with external SD slots like the QL-SD would be a worthy SGC system internal replacement.
Mabye, but I'm not sure about this - a majority of the black box users may want to keep the original mainboard in place and prefer a "classic" SGC-like plugin card.
Dave wrote:Anything I can do to support or encourage that, even if it is just cheerleading from the sidelines, you have my 100% support.
Many thanks, I have the same hopes and best wishes for your mainboard project! You and Nasta deserve at least one major success.


User avatar
Peter
QL Wafer Drive
Posts: 1948
Joined: Sat Jan 22, 2011 8:47 am

Re: Beyond Super Gold Card

Post by Peter »

Regarding the speed issue, here's a quote from a recent post in the QTOP benchmark topic:
janbredenbeek wrote:BBQL with Minerva and (non-super) Gold Card: 5.640
Q68: 24.125 (SMSQ/E)
Raspberry Pi 3B+ with uqlx and Minerva: about 103
This means that even a Q40 or a potential Q68 running from SRAM or cache (roughly 3 times faster than the Q68 figure above) is outperformed by emulation on a Raspberry.

For me, figures like this prove again that ideas of native hardware with Raspberry as coprocessor are pointless. Such a machine would need to maintain Raspberry OS and application software anyway, and it would need to wait for the Raspberry to boot. That combination leaves almost no practical reason to have native hardware at all - I wouldn't see why not also emulate the CPU and gain speed.

I think the only motivation for native hardware "Beyond Super Gold Card" can be a philosophy beyond practicality and speed. Something along the lines of conceptual purity, and the challenge of finding software solutions on the QL side, rather than taking the easy way of Windows/Linux/microcontroller.


Derek_Stewart
Font of All Knowledge
Posts: 3900
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Beyond Super Gold Card

Post by Derek_Stewart »

Hi, Peter,

The Raspberry PI3B+ had a 1.4GHz 64-bit quad-core processor, is this a fair comparison to a single core processor running at 40Mhz.

I have three Raspberry Pi3B+, which are not any use, except for one that ised on Retroprinter.


Regards,

Derek
User avatar
XorA
Site Admin
Posts: 1357
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Beyond Super Gold Card

Post by XorA »

For me, figures like this prove again that ideas of native hardware with Raspberry as coprocessor are pointless.
I would have to agree with Peter on this.

And AROS (Amiga Research Operating System, an AmigaOS 3.1 compatible OS) proves you can take and old 68k OS and "convert" it to other CPUs. It even automagically runs a 68k emulator for old executables so they function on the new CPU seamlessly.


stevepoole
Super Gold Card
Posts: 710
Joined: Mon Nov 24, 2014 2:03 pm

Re: Beyond Super Gold Card

Post by stevepoole »

Hi folks,
Thanks to covid19 confinement,I am adapting some old QL programs to run on QPC2.

On my QL, they savem using sbytes flp1_screen, SCR_BASE, 32768 and loadem using lbytes flp1_screen, scr_base.
The QL loadem works fine, but on QPC2 I just get a tiny thumbnail image in the top left hand corner of the window.

Is it possible to load QL screens into QPC2 , with the latter set to 512x256 resolution....
( These old screens cannot be regenerated on QPC2, as the corresponding programs are on old failed microtapes....)

Regards,
Steve.


Post Reply