No Bright in the Border ??

edited May 30 in Hardware
Hello,
is there any hardware reason for which its difficult or impossible to use BRIGHT inside the border?
The asm instruction is setting bit 0-2 int port 254 and the port instruction itself has only 3 bits space for colour information.
But, if there was a different port that allowed More colour info like the info set ineg ATTR_P , would zx be able to produce bright inside the border aswell ?? or flash?
Post edited by Crisis on
my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file

Comments

  • And how exactly would you do that?
    I wanna tell you a story 'bout a woman I know...
  • If there was a different port then there would be different hardware, because I/O ports control hardware.

    The hardware in the ULA does what it is designed to do, and not anything else. If they’d designed it differently, they could have changed and aspect of how it works, including colours abs borders. They were, however, quite constrained by the number of logic cells in the ULA, and constrained by cost from choosing a larger ULA.
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
  • edited May 30
    colonel32 wrote: »
    If there was a different port then you really mean there would be different hardware, because I/O ports only exist as a mechanism to control hardware.

    The hardware in the ULA does what it is designed to do, and not anything else. So you could say that it’s impossible. If they’d designed it differently, they could have changed any aspect of how it works, including colours and borders. They were, however, quite constrained by the number of logic cells in the ULA, and constrained by cost from choosing a larger ULA.

    Post edited by colonel32 on
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
  • edited May 30
    The original aim of the new machine (ZX82 that later on was named as the ZX Spectrum) from Sinclair (the follow in from the ZX81) was to have a colour display.

    It's development was constrained by a number of things, including a short development time (Sinclair wanted it to launch it on 23rd April 1982), and keeping the cost down. One way to keep the cost low, was to cram as much of the circuitry inside a single custom chip as possible - the ULA.

    The type of ULA chosen was the 5000 series. this type has 440 logic cells. Various compromises had to be made to get all the required functionality in the ULA, in the end, there was only a small number of logic cells left free.

    So I very much doubt that providing a bright bit for the border was even considered (the D type flip flop needed to store one bit requires 6 cells on its own).

    Mark
    Post edited by 1024MAK on
  • Hi Colonel32 , If i get your remark right you say that there is no bright information reserved inside the ula for the building of the border signal, despite that cell/space is reserved for the screen part.
    I do not have the idea there would be a secret or forgotten port or port situation to make it possible or reachable, yet, it was little thought why, which you answered. There is no 'paper' nor 'ink' nor 'bright' , there is 'colour' available and thats all. thanks
    my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
  • It is something I'd wondered about many moons ago but decided it was the ULA and by design.

    Best you can sensibly do is set the lower screen area (as in "lines 22 and 23") to be bright if you wish, that's easy enough.

    Potentially I think if it was possible to say set a bright border it may of been possible to also set its flash attribute too, probably would mean using the full 255 byte setting to determine the colour though same as ATTR_ (system variable) values.

    I tend to set them both (main and lower areas) to 71 which gives me bright white text on black. Something that you can't usually set, that is a bright lower screen area without a POKE.
  • As said above, the real limitation is the ULA. Each and every extra feature or function will require more logic cells...

    It's likely there is no available space in a 5000 series ULA as used in issue 1 and issue 2 boards. Extra features and correction of design errors (I/O contention handler, lower RAM refresh, etc) could have been included when production switched to the larger 6000 series ULA (which we suspect was developed by Ferranti specially for Sinclair) but Sinclair did not use this opportunity :(

    Mark
  • I've thought (vaguely) that when the + model was launched there was sadly a bit of a missed opportunity to do a few changes such as that as well as update the ROM to fix a few bugs etc.

    I realise this would of likely meant 'home upgrades' were not always possible unless the ULA was socketed and it may of involved some soldering to change or add some kind of erm 'bodge dead cockroach for new features' too, but it would of given more distinction to the + model perhaps, possibly increasing sales.

    I don't have figures but talking of sales I wonder how many 'DIY upgrade' + kits were sold in one year compared directly to the rubbery keyed model and the + model, as in three sets of figures for one year. That would be a fair comparison perhaps.

    Some might say "some software might not work properly now" with the 'new' model, possibly true however you could maybe compare that to 16K vs 48K and perhaps more accurately later on the fact that some existing titles did not like the 128K models, moreso the later +2 and +3 A/+B black models...

  • edited May 31
    I think that by the launch of the plus model, compatibility had become king. Especially after the issue 3 board release caused trouble with some (poorly written) software.

    My thoughts on what the plus should have been are
    elsewhere.

    Mark
    Post edited by 1024MAK on
  • 1024MAK wrote: »
    I think that by the launch of the plus model, compatibility had become king. Especially after the issue 3 board release caused trouble with some (poorly written) software.

    My thoughts on what the plus should have been are
    elsewhere.

    Mark
    Ah yes, a topic I started. I recall your post and others. Not a million miles off (imo) what could of been done with the IF1 for instance perhaps but that's something for another topic.

    For the moment, regarding a bright border, well best I can suggest for now is 23624 , 71 :D , at least its bright white. Or perhaps 98 would be a change if bright green with blue ink is required instead. :)
  • edited May 31
    1024MAK wrote: »
    I think that by the launch of the plus model, compatibility had become king. Especially after the issue 3 board release caused trouble with some (poorly written) software.

    My thoughts on what the plus should have been are
    elsewhere.

    Mark

    Its there better port buffering on the list? they are very vulnerable afaik and could probably use some 'half-diodes' inbetween. but i am not a hardware man, else i would have repaired my datapoint kathode-pcb.

    silly example about the poke
    10 BORDER 7: BRIGHT 0: CLS: PAUSE 100: BRIGHT 1: CLS
    12 PRINT #0; AT 0,0; BRIGHT 1;" ": PAUSE 100
    15 POKE 23624,71: PAUSE 100: PRINT #0; AT 1,0;"X": PAUSE 100: CLS
    25 POKE 23624,56: PAUSE 100: PRINT #0; AT 1,0;"X": PAUSE 100: CLS
    

    edit:
    and
    the lower two lines ARE screen and not border at all, so the bordr is still not influenced
    Post edited by Crisis on
    my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
  • Buffering the expansion port was never likely, the cost would be too great with not much value added.
  • 1024MAK wrote: »
    Buffering the expansion port was never likely, the cost would be too great with not much value added.

    Not much value added?
    so a transistor chip wont burn that easy?

    my old website http://home.hccnet.nl/c.born/ has changed to http://www.cborn.nl/zxfiles/ so just click it and select a file
  • Not much value added as far as marketing is concerned.

    Let's see, will the £149.99 machine with a buffered expansion port sell as well as the £129.99 machine with the same features but without a buffered expansion port...

    Of course I would have preferred the expansion port to be buffered, but then, I would also have liked a proper keyboard like on the Acorn or Commodore machines...

    Mark
  • 1024MAK wrote: »
    Of course I would have preferred the expansion port to be buffered, but then, I would also have liked a proper keyboard like on the Acorn or Commodore machines...

    Mark
    Must admit the few times I'd used a CBM64 keyboard I did not like it that much (breadbin one , not the later 'shape) although I agree on the Acorn comment, various revisions of keyboards as you know including that slightly offputting membrane one.

    On topic itself regarding keyboards, the erm solution here seems to be the Oric Atmos, as its only a tiny bit bigger than the 48K rubbery keyed speccy (L x W that is) and its got a half decent keyboard, not to be confused with the earlier Oric-1 with its squishy keys, if only I could get mine to output some kind of video signal um lol, its on the "long term project list"

  • Also, several other colour computers of the era didn’t have programmable coloured borders at all. It wasn’t really an essential feature for colour programs, so the fact the Spectrum has one at all is somewhat of a bonus, even without brightness.
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
  • colonel32 wrote: »
    Also, several other colour computers of the era didn’t have programmable coloured borders at all. It wasn’t really an essential feature for colour programs, so the fact the Spectrum has one at all is somewhat of a bonus, even without brightness.
    True. :) BBC Micro springs to mind here, no "border" as such.

  • edited June 3
    spider wrote: »
    colonel32 wrote: »
    Also, several other colour computers of the era didn’t have programmable coloured borders at all. It wasn’t really an essential feature for colour programs, so the fact the Spectrum has one at all is somewhat of a bonus, even without brightness.
    True. :) BBC Micro springs to mind here, no "border" as such.
    There’s a long list, starting with the ZX80, ZX81, QL, Jupiter Ace, Electron... etc..

    But I bordered of this now :))

    Mark
    Post edited by 1024MAK on
  • I think the border just makes up a little bit for the quite low resolution of the Spectrum. Not so much need or room for it when you have 320 or 640 pixel wide displays!
    It's a convenient way of showing loading bars but not much else...
  • I think the border just makes up a little bit for the quite low resolution of the Spectrum.
    It’s more of a way of ensuring the entirety of the active screen area can be displayed by a standard TV (I’m talking overscan), and to minimize the geometry distortion around the edges of the screen. On the Spectrum in particular, this also provided enough time for the CPU to operate uninterrupted, thus increasing the machine’s perceived speed of operation.
    Every man should plant a tree, build a house, and write a ZX Spectrum game.

    Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
    and zasm Z80 Assembler syntax highlighter.
    Member of the team that discovered, analyzed, and detailed the floating bus behavior on the ZX Spectrum +2A/+3.

    A few Spectrum game fixes.
  • The Next has a few modes which extend 64 pixels into the border in all four directions. Even with 8x CPU speed, the amount of time the "beam" is outside the active pixel area is considerably reduced, so you have to design your code quite carefully to avoid tearing.
    Robin Verhagen-Guest
    SevenFFF / Threetwosevensixseven / colonel32
    NXtel NXTP ESP Update ESP Reset CSpect Plugins
Sign In or Register to comment.