Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

JamesD

Members
 View Profile  See their activity

  • Content Count

    8,999

  • Joined

  • Last visited

  • Days Won

    6

Posts posted by JamesD

  1. Posted

    On 9/18/2019 at 8:28 PM, ChildOfCv said:

    ... if this is actually your argument, then what was that irrelevant FPGA mention about?

     

    But to answer your question, he left a HUGE amount behind with that decision.

    • Address space is now less than 1% of what it would have been.
    • To make up for that, he added the extra logic for bank swapping (which is more complicated than the 2 chips he couldn't abide, BTW).
    • Even with bank switching, you only get 2MB where the first choice offered 16MB.
    • To fit sanely into this 64K address space, everything on the video card is, control and memory, is accessed through 4 ports.  The equivalent of having to do all surgery anywhere on the body through the butt hole.  If I wanted to do that, I'd get a TMS99x8 chip.
    • The BIOS and OS are written to work with the hardware, and the developers will also be stuck dealing with this hardware.

    In short, for the sake of less complexity, he added more complexity.

    I'm pretty much regurgitating his argument.
    My argument is that it's his project, so he can do whatever he wants.  If you don't like it, don't buy it. 
    Since you know so much, make your own.  If your's is better, maybe more people will buy it.
     

    • Like 1

  5. Posted

    On 9/15/2019 at 1:23 PM, ChildOfCv said:

    That fear seems irrational.  The address latch circuit is shown near the end of the data sheet and requires only a couple of extra chips.  HC components should easily handle the faster speed.  Modern FPGAs and such certainly can.  Even modern SRAM can keep up with that speed.  The only thing left is to make sure that the lines have about the same length as you run them.

    I know he was trying to avoid using FPGAs except for the video chip.
    Not sure I'd call it irrational, probably just playing it safe.  Get something working, then upgrade it.

  6. Posted

    Part of David's dream is for it to be an easy to program, inexpensive, educational computer.
    The feature creep had turned it into something way beyond that, and it he wasn't certain they could make the multiplexed buss of the 65816 work at the higher speed.  You have to latch the upper address lines in the first part of the buss cycle.  That makes you run the parts on the buss faster than the CPU, and you start having to worry about how fast the parts are.  Instead of 8 MHz, you are now worrying about parts that might function at 16 MHz, or at least settle times on things like RAM have to be fast enough.  At the very least, it may make the machine more expensive than the intended goal.
     

  8. Posted

    19 hours ago, ubersaurus said:

    At this stage, probably a Cosmac VIP. I got my Spectrum last visit to the UK, and while an MSX would be neat the VIP is just so weird!

     

     

    An Altair 8800 would also be neat if only to run that Space War conversion to it.

    The VIP is more like the early single board machines like the KIM 1... but with a really limited video added on. 
    I'd love to spend some time programming the CPU, but the rest of the hardware is so limited, it's hardly worth messing with.  
    It's cool from a historical standpoint though.

    I think I'd skip the Altair and go with a modern equivalent.  There's a work alike machine out of Japan with a Z180 (64180?) that looks pretty cool.
     

  14. Posted · Edited by JamesD

    Play Rainbow Six Siege, free this week on UPLAY, EPIC Games launcher, and Steam.
    If you like it, you can buy the full game at a discount.  UPLAY said $8.
    Details:
    https://support.ubi.com/en-US/Faqs/000045901

    You can also "GRAB ASSASSIN'S CREED: ODYSSEY'S "FIELDS OF ELYSIUM" FOR FREE! (08/26 - 09/01)" on UPLAY
    https://support.ubi.com/en-US/News/000046890/Grab-Assassin-s-Creed-Odyssey-s-Fields-of-Elysium-for-free-08-26-09-01-ACOD

    "The Assassin’s Creed Odyssey base game is required to access season pass content, including the Fields of Elysium episode."

  18. Posted

    On 8/12/2019 at 9:20 PM, JamesD said:

    Maybe the ORIC did, since it also has ELSE, where earlier 6502 versions didn't.  The ORIC came out after the Atari version.
     

    The ORIC does support integers, but you have to specify them with the % sign at the end, which takes longer to parse, but at least it supports them.
    Example:
    A%=1:DIM I%(size)

  19. Posted

    2 minutes ago, Faicuai said:

    I would be REALLY surprised if MS-Basic II on Atari is the only 6502 version that supports Integer declaration...

     

    Apple II, Commodore VIC20 / C64 / Plus/4 / C128... nope. 
    Maybe the ORIC did, since it also has ELSE, where earlier 6502 versions didn't.  The ORIC came out after the Atari version.
    Maybe some of the Tompson machines (6809) had int, but I'm not sure.
    It was common on a lot of Z80 versions except really cheap machines.
     

     

    12 minutes ago, Faicuai said:

    ...However, I must inform you about its limitations, too... You cannot specify a variable (per my last attempt, as I get an error)... When you DEFINT with an alpha "X", all names beginning with "X" will be handled as 16-bit integers... that is also part of what happens on MS-Basic85-CP/M80... 

    That one's new to me.  I don't remember that on the Model I & III.
    The loop variable X should be changed to something else then.

  20. Posted

    I'm pretty sure a brought up the fact that everything the MC-10 did was floats.
    The Atari version may be the only 6502 version that supports INTs, and none of the 68xx versions I'm aware of do.
    Try changing the code like this:

    0 DEFINT I,M,I0,IH,IL,J,P,X,O,T,Q,L,N,S
    1 J=0:R1$="":M=J:I0=J:IH=J:O=1:T=2:Q=-1
    44 IH=INT(IW/T):I0=I(IL+IH)

  22. Posted

    4 hours ago, Faicuai said:

    Check current optimizations gains. vs. just enabling DEFINT declaration on source header.

     

    All-in-all, I am initially inclined to think that the biggest contribution in execution timing differences are, in reality, actual implementation differences between MS Basic itself, more than just CPU-bandwidth alone (not that the latter is not a factor, but their relative contribution, that is).

     

    This would be pretty much in-line with Doctor's initial comments, though...

     

    I also wonder how the BBC Micro would handle the original SORTBAS7.MBT source list, though. We'll see...

    DEFINT requires support for integers.  

  23. Posted

    Speeding up the interpreter's variable lookup code should help speed this up significantly. That is already on my to do list.
    Just changing the code a bit offers significant improvement.  The code below isn't optimal, but it's better without really altering the algorithm. 
    This code, which includes turning off the display for the memory move on the Plus/4, drops the time to a little under 24.5 minutes.
    The MC-10 with new ROM completes it in 22:36.  Even a minor patch to the Plus/4 should make it pass the MC-10. 
    More efficient algorithms make a big difference, but ultimately, MHz matters.

    Ditching multi-character variable names completely would make this faster.  MS BASIC only recognizes the first 2 characters anyway.
    Improving the order variables are defined in at the top could speed it up, and changing a few more lines of code might help cut a few more minutes off of the time.
    Using machine language for the insert memory move would probably offer the biggest improvement since it would bypass all the variable lookups and expression evaluation code, but then that's not benchmarking BASIC anymore.  It would be interesting to see how much time is spent in that loop though.

    Spoiler

    0 J=0:R1$="":M=0:I0=0:IH=0:O=1:T=1/2:Q=-1
    1 REM DEFINT I,J,L,M,N,S
    2 NL=561+O:S=561+O:IMW=5:LB=T:MS=10
    3 DIM I(S),N$(NL),R1$
    '18 REM 
    '20 POKE ANTADR,ANTON*ANTIC:POKE TH,0:POKE TLB,0
    4 PRINT  "Loading & Sorting: ":J=0
    5 FORX=0TO1STEP0:READ R1$,A,B,C:IFR1$="EOL"THEN70
    6 J=J+O:I(J)=J:N$(J)=R1$:IFJ<LBTHENNEXTX
    '30 REM 
    7 PRINT".";:IH=J-O:IL=O:IFJ<MSTHEN52
    8 FORP=0TO1STEP0:IW=IH-IL:IFIW<IMWTHEN52
    44 IH=INT(IW*T):I0=I(IL+IH)
    46 IF R1$<N$(I0)THENIH=IL+IH:NEXTP
    48 IL=IL+IH:NEXTP
    '50 REM 
    52 IH=J:FORM=IHTOILSTEPQ:I0=I(M):IFR1$<N$(I0)THENIH=M
    58 NEXT:IFIH>=JTHENNEXTX
    60 I0=I(J):IL=IH+O:FORM=JTOILSTEPQ:I(M)=I(M-O):NEXT
    62 I(IH)=I0:NEXTX
    '64 REM
    '66 X=PEEK(TH):Y=PEEK(TLB)
    70 PRINT:PRINT"Printing Sort Results..."
    72 FORM=OTOJ:I0=I(M):PRINT".";N$(I0);:NEXTM
    '74 REM 
    92 PRINT:PRINT:PRINT"Processed ";J;" records!"
    '94 PRINT  "Elapsed: ";(X+256*Y)/VF;" sec."
    96 END 
    98 REM

    'Plus/4 changes
    '0 TIMER$="000000":J=0:R1$="":M=0:I0=0:IH=0:O=1:T=1/2:Q=-1
    '5 FORX=0TO1STEP0:POKE65286,27:READ R1$,A,B,C:IFR1$="EOL"THEN70
    '52 POKE 65286,0:IH=J:FORM=IHTOILSTEPQ:I0=I(M):IFR1$<N$(I0)THENIH=M
    '62 I(IH)=I0:NEXTX:POKE65286,27
    '96 ?TI/60:END
     

     

  25. Posted

    As I've said before, MS BASIC doesn't tokenize constants, including line numbers in GOTOs, and I haven't made any optimizations dealing with speeding up GOTO, or GOSUB yet.
    After seeing this, it looks like a generic memory copy may be used to copy from one float to another. 
    If that's the case, I'll add a special case for that. It would speed up a LOT of things.

    FWIW, minor changes to the code cuts off over 5 minutes, and a few more changes might drop another 5. 
    The memory move seems slow.  I'll have to see what code is being called.  

    I am NOT timing the Apple.  I won't sit around that long. 
    The Plus/4 does it in about 35.5 minutes without blanking the screen.
     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...